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This publication describes the functions, principal 
features, and use of the Input/Output Control System 
supplied by IBM as psirt of the Model 20 Tape Program- 
ming System (TPS) . This Input/Output Control System 
(IOCS) facilitates the programming of input/output 
operations. 





The following subject 
tion statements that des 
cessed, (2) the initiali 
makes the files availabl 
or data output, (3) the 
that cause input/output 
tion macro instructions 
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cribe the files to be pro- 
zation macro instruction that 
e to the system for data input 
processing macro instructions 
operations, and C4) the comple- 
that terminate processing of 
the files used in an 



Also included is a section containing general pro- 
gramming considerations, e.g., information about block- 
ing and deblocking of records , combinations of input/ 
output and work areas, tape error routines , and regis- 
ter usage. Programming examples are also given. 

Readers of this publication should be thoroughly 
familiar with the contents of the SRL publication IBM 
System/360 Model 20, Functional Characteristics , Form 
A26-5847. 

Titles and abstracts of other related publications 
are given in the publication IBM System/360 Model 20 
Bibliography , Form A 26-3565. 







PBEFflCE 



This publication is intended for Model 20 
programmers using the TPS Input/Output Con- 
trol System. 



Depending on the equipment and programs 
used, the following publications are also 
required: 



The reader should be familiar with basic 
programming concepts and with the operating 
principles of his system as described in 
the following SEL publications: 

IBM_System/360_Jodel_20 

• F unct ional Characteristics, Form 
A26-5847;" 

• Tape _Programminq SYStem^,,, Co ntr ol a nd ; 
S er vie e_ Programs , Form C24-9000; 

• Disk, and Tape P rogr amming _SysteaSj, 
Assembler Languag e, Form C2t|-9002. 



IBH System/360 Model 20 

• Disk and Tape Programming Systems, 
Input/Outp ut Control System for the IBM 
im9 and 1259 Magnetic Character 
Readers, Form C33-6C01; 

• Input/Output— Control System for the 
Binary Synchronoas^Coamunications 
Ada£ter, Form C33-4001; 

Titles and abstracts of other related 
publications are given in the publication 
IBi5_Sjstem/360 Model 20 B ibliography , Form 
A26-3565. 
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ITechnical Newsletter N33-8552. The changes are associated 

I mainly with the introduction of Submodel 5 of the Model 20. 

jchanges to the text, and small changes to illustrations, 

I are indicated by a vertical line to the left of the change; 

] changed or added illustrations are denoted by the symbol • 

I to the left of the caption. 
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IThis edition applies to program version 4, modification 

I level of IBH Systera/360 Model 20 TPS IOCS, and to all 

jsubsequent releases until otherwise indicated in new edi- 

Itions or Technical Newsletters. Changes are continually 

|made to the specifications herein; before using this 

I publication in connection with the operation of IBM Sys- 
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I the edition that is applicable and current. 
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INTBODDCTION 



This publication describes the functions, 
principal features, and use of the Model 20 
Input/Output Control System for punched- 
card equipment and magnetic tape. 

The Model 20 TPS Input/Output Control 
System (IOCS) is a set of tested routines, 
in assembler language, provided by IBM. 
The IOCS routines are part of the Model 2C 
Tape Assembler macro library. The program- 
mer can utilize these routines by simply 
issuing appropriate macro instructions in 
his program. 

A major part of most programs written in 
Assembler language consists of routines 
required to read data into the system and 
to print (punch or write on tape) the 
results of the processing performed on the 
input data. By utilizing the IOCS rou- 
tines, the programmer can save programming 
time because he can concentrate on solving 
his problems and let the IOCS handle data 
input and output operations. 



Also, the 
of the time s 
means of over 
tions with ea 
of the Model 
throughput, 
used, the IOC 
compute, writ 
which allows 
lapped with p 



IOCS routines take advantage 
haring feature (this is a 
lapping input/output opera- 
ch other and with processing) 
20, thereby optimizing 
When a Model 20 Submodel 5 is 
S can make use of the read/ 
e/compute overlap feature, 
tape-data transfer to be over- 
rocessing. 



The IOCS provides routines for: 

• transfer of data from input/output 
devices to main storage and vice versa, 

• checking and writing of labels (if any) , 

• blocking and deblocking of records, 

• switching between input/output areas 
under certain conditions, and 

• performing input/output control func- 
tions such as card stacking, tape re- 
wind, etc. 

USE AND FUNCTIONS OF IOCS 



plete program now consists of both source 
program statements and tailored routines 
from the macro library in Assembler lan- 
guage. In subsequent phases of the assem- 
bly, the entire object program is 
assembled. 

Two types of macro instructions are 
required to cause the desired input/output 
functions: declarative macro instructions, 
which are referred to as definition state- 
ments, and imperative macro instructions. 

The programmer uses definition state- 
ments to specify the input/output routines 
he requires for his particular application. 
Based on the information provided, these 
routines are selected and developed at as- 
sembly time. 

A linkage to the selected input/output 
routines is required at each point in the 
program where an input/output operation is 
to occur. The user need not provide these 
linkages. He only writes an imperative 
macro instruction in his source program at 
the point he desires the input/output 
operation to occur. When an imperative 
macro instruction is read during assembly 
of the source program, the Assembler auto- 
matically inserts the required linkages to 
the selected input/output routines. 



Other Programs. ,Used_ by . the IOCS 



When a program using the IOCS 
some of the Basic Monitor rou 
used. Therefore, programs us 
require the Basic Monitor pro 
main storage when they are be 
The Job Control program is re 
user's program requires job c 
to be read at the beginning o 
execution. The Job Control p 
required if the IOCS is to ma 
read/compute, write/compute o 
feature. 



is executed, 
tines are 
ing the IOCS 
gram to be in 
ing executed, 
quired if the 
ontrol cards 
f program 
rogram is also 
ke use of the 
verlap 



For further information regarding the 
Basic Monitor and the Job Control programs, 
refer to the SRL publication IBM System/360 
Model 20, Tape Programming System, Control 
and_ Service_Proc[i:ams_Form C24-9000. 



When a program utilizing the IOCS is 
assembled, the macro instructions specify 
which of the IOCS routines are to be called 
from the macro library. The routines are 
extracted, tailored according to the 
operands in the macro instructions, and 
inserted into the source program. The coro- 



MACHINE BEQDIREMENTS 

This section describes the minimum and 
maximum configurations for assembling and 
executing IOCS routines of the tape- 
resident system. 
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K inimua System Configuration 



Submodel 2 



• An IBM 2020 Central Processing Unit, 
Model C2 (8192 bytes of main storage) ; 

• an IBM 2415 Magnetic Tape Unit, Model 2, 
3, 5, or 6; 

• One of the following card-reading 
devices: 

IBM 2501 Card Reader, Model A1 or A2, 
IBM 2520 Card Bead Punch, Model A1, 
IBM 2560 Multi- Function Card Machine, 
Model A1 : 

• One of the following printers: 

IBM 1403 Printer, Model N1, 2, or 7, 
IBM 2203 Printer, Model A1. 



Submodel 5 



• An IBM 2020 Central Processing Dnit , 
Model C5 (8192 bytes of main storage) ; 

• the same input/output units as described 
above for Submodel 2. 



M aximum System Configuration 



Submodel 2 



• An IBM 2020 Central Processing Unit, 
Model D2 (16,384 bytes of main storage) ; 

• an IBM 2415 Magnetic Tape Unit, Model 1 
through 6; 

• an IBM 1442 Card Punch, Model 5; 

• an IBM 2501 Card Reader, Model A1 or A2; 

• one of the following card units: 
IBM 2520 Card Read Punch, Model A1, 
IBM 2520 Card Punch, Model A2 or A3, 
IBM 2560 Multi-Function Card Machine, 
Model A1 ; 

• one of the following printers: 

IBM 14C3 Printer, Model N1, 2, or 7, 
IBM 2203 Printer, Model A1 ; 

• a Binary Synchronous Communications 
Adapter (feature No. 2C74) ; 

• one of the following magnetic character 
readers: 



IBM 1419 Magnetic Character Reader, 
Model 1 or 31 , 

IBM 1259 Magnetic Character Reader, 
Kodel 1, 31, or 32. 



Submodel 5 



An IBM 2020 Central Processing Unit, 
Model E5 (32,768 bytes of main storage) ; 

the same input/output units as described 
above for Submodel 2. 



Notes: 



Only three tape drives are required for 
assembly if no literals are used in the 
source program and no object-program 
output on tape is required. 



At 
reg 
the 
if: 



least one 9-track tape drive is 
uired. If 7-track tapes are used, 
data conversion feature is required 

EBCDIC characters other than those 

included in the ECE character set 

are to be written, or 

the tape file to te read has teen 

created using the data conversion 

feature. 



The ECE character set consists of 
the digits through 9, the alphabet, 
and 28 special characters, all of which 
can be represented ty the six rightmost 
bits of a byte. 

The translate feature is required if 
7-track tapes are used and standard 
labels must be read from or written on 
these tapes. 



MACHINE FEATURES SUPPORTED 



The following input/output devices are sup- 
ported by the IOCS: 



s 



1403 

1442-5 

2203 

2501 
2520 
2520 
2560 

2415 

1259 
1419 



Printer 

Card Punch 

Printer, standard and dual feed 

carriage 

Card Reader 

Card Punch 

Card Bead-Punch 

Multi-Function Card Machine (MFCM) , 

including Card Print feature 

Magnetic Tape Unit and Control, 

Models 1 through 6 

Magnetic Character Reader 

Magnetic Character Reader, Models 1 

and 31. 
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The IOCS also supports: 

• Binary Synchronous Communications Adapt- 
er (Feature No. 2074). 

• Additional main storage up to 16,384 
(Submodel 2) , or 32,768 hytes (Submodel 
5) . 

Note_l: The Data Conversion feature is 
required if 7-track tapes are to be used 
and either 

a. EBCDIC characters other than those 
included in the BCD character set are 
to be written, or 

b. the tape file to be read has been 
created using the Data Conversion 
feature. 



The BCD character set consists of the 
digits through 9, the alphabet, and 28 
special characters, all of which can be 
represented by the six rightmost bits of a 
byte. 



Not e_ 2 ; The Translate feature is required 
if 7-track tapes are used and standard 
labels must be read from or written on 
these tapes. 



JIote_3: The object program can make use of 
the Bead/Compute, Write/Compute Overlap 
feature if a Submodel 5 is used. 
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DEFINITIONS 



RECORD 

A record is a unit of information comprised 
of one or more alphameric and/or special 
characters. For the purpose of the IOCS, 
such a unit of information is referred to 
as a logical record. For transfer from the 
CPU to magnetic tape and vice versa, data 
is compiled in physical units of informa- 
tion that are referred to as blocks. A 
block may consist of one logical record 
only or an integer multiple thereof. 

The IOCS accepts three record formats. 
They are: (1) fixed length, (2) variable 
length, and (3) undefined. Fixed and vari- 
able length records may be blocked or 
unblocked. The record formats and the 
allowable record types are described below: 



V ar i a b le - L e na t h_ J e co r d s 

Variable-length records are logical records 
of a set of records that vary in length 
(applies only to records on magnetic tape) , 
They may be blocked or unblocked. If these 
records are unblocked, the IOCS handles 
each logical record the same way as a 
block. If they are blocked, one or more 
records of variable length make up one 
block, 

A variable-length record must contain a 
record-length indication. The first four 
bytes of a variable-length record are used 
for this purpose. The first two of these 
four bytes show the number of bytes con- 
tained in the record in binary notation. 
The remaining two bytes contain binary 
zeros. 



Fixed-Lenqth Records 
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tape) , one or more 
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The record-length indication must be 
provided by the user whenever he is creat- 
ing a variable-length record. The four 
bytes required for the length indication 
are included in the byte count for the 
record, 

A block-length indication is required 
for each block. This block-length indica- 
tion consists of four bytes that precede 
the record-length indication for the first 
(or only) logical record of the block. 



r- 



Record 
A 



Record 
B 



Record 
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Record 
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Record 
E 



Record 
F 



Record 
G 



Record 
H 



IBG = Inter - Block Gap 
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a. Unblocked Record Format 
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b. Block Record Format 
Figure 1, Example of Fixed-Length Records on Tape 
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The first two of these four bytes indicate, 
in binary notation, the number of bytes 

I contained in the block. The remaining two 
bytes contain binary zeros. The block- 
length includes the four bytes for the 
block-length field itself. 

Although the block-length indication 
does not appear in the record that is fur- 
nished to or made available by the problem 
program, the programmer must define input/ 
output areas that are large enough to 
accommodate the four bytes required for the 
block-length indication. 

Figure 2 is a schematic representation 
of variable-length records on tape. 

Undefined _Format 

If the record format of a file is referred 
to as undefined, the record characteristics 
are unknown to the IOCS. Because each 
block is treated as an unblocked logical 
record, any blocking or deblocking must be 
performed under control of the problem 
program. 

Sjgcord_Formats_Permitted 

The formats that can be used depend on the 
type of input/output file as follows: 

C ar d_ an d_Pr 1 n t er _F i le s : Only unblocked 
records of fixed length are allowed. 

Tape, Files ; Eoth blocked and unblocked 
records of fixed and variable length and 
records of undefined format are allowed, 
except when a file is to be read backward. 
When a file is to be read backward, 
variable-length blocked records are not 
allowed . 



FILE 

A file is a set of records that contains 
related information, e.g. an inventory 
file of part numbers, an employee file, or 
a customer file. Such a set of records may 
be punched into cards (card file) , printed 
on forms (printer file) , or written on 
tape (s) (tape file) . For the purpose of 
the Model 20 IOCS, files can be of two 
types: simple and combined. 

1 Sira£le_File 

A set of records that are all either 
read, printed, punched, card printed, 
or written on tape during one pass 



through the system. 

Exception: A simple file that is eith- 
er read or punched on the 2560 MICM may 
also be card printed during the same 
pass. 

2 . Combined_ File 

A set of card records, some or all of 
which will be read and/or punched dur- 
ing one pass through the system. The 
records comprising a combined file must 
be fed from one hopper. A combined 
file that is processed on the 2560 HICM 
may also be card printed. 



VOLUME 

A volume is a tape reel of data. A volume 
may contain only part of a file (a multi- 
reel file, for example) or many files. 



LABELS 

A label is a tape record used to identify 
either a volume or a file. A label may be 
standard or non-standard. It is considered 
standard if it meets the format require- 
ments for standard tape labels. 

Label processing and formats of labels 
are described in detail in the SEL publica- 
tion IBM System/36Q_Model.,2p, Tape _ grog ram- 
J''J-.sg..Jlstgg'jr Control and Service Programs, 
Form C24-9000. 



CAED/PEINTEE CVEBIAP KCEE 



This is a mode of operation that allows the 
execution of card and printer I/C opera- 
tions and processing to be performed simul- 
taneously. A mode of operation that does 
not permit I/O operations and processing to 
be executed simultaneously is referred to 
as non-overlap mode. 



EEAD/CCMEUTE, WEITE/CCKEUTE CVEBLAP FEATOEE 



When a Submodel 5 is used, the read/ 
compute, write/compute (EHC) overlap fea- 
ture is available. When the CPU is running 
in the RWC overlap mode (under control of 
the overlap monitor) , data transfer to or 
from tape units is overlapped with 
processing. 
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Record 1 
Data 



BL 
XX 00 



RL 
XX 00 



Record 2 
Data 



RL = 80 
BL = 84 



83 



103 



RL = 100 ► 

BL = 104 ^ 



a. Variable Length - Unblocked Record Fonnat 



BL 



XX 00 



RL 



XX 00 



Record 1 
Data 



3,4 
I 



RL = 80 



*•- 



RL 



XX 00 



Record 2 
Data 



83 84 
I 



87 



RL = 100 
BL = 234 



RL 



XX 00 



183 i 184 
I 



"►-♦■ 



187 



Record 3 
Data 



mm^im, 



233 



RL = 50 



I 



b. Variable Length - Blocked Fonnat 



• Figure 2. Example of Variable-Length Records on Tape 
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KACEO INSTRUCTIONS 



Macro instructions are provided to reduce 
the amount of repetitive coding, A nacro 
instruction given by the programmer causes 
the generation of a set of individual 
machine instructions at the time of assem- 
bly. The generated instructions cause the 
desired machine function to be performed 
when the program is executed. 



In this publication, the following con- 
ventions apply to the description of the 
macro instructions: 



Definition Statements: DTFSE and DTFMT 
(both including detail entries) , ETFEH 
and DTFBG. 

Initialization Hacro Instruction: 

CFES. 

Processing Macro Instructions: GIT, 
PUT, CNTRL, CHDPR, EOM, LOM, PRTCV, 
KAITC, LBRET, EELSE, and TEONC. 

Completion Bacro Instructions: CLOSE 
and FEOV. 



1. Upper-case letters and punctuation 
marks (except as described in items 3 
and 4 below) represent information that 
must be coded exactly as shown. 

2. Lower-case letters and terms represent 
information that must be supplied by 
the programmer. 

3. Information that is contained within 
brackets [ ] represents an option that 
can be included or omitted, depending 
on the requirements of the program. 

4. A series of three periods enclosed by 
commas indicates that a variable number 
of items may be included. 

The programmer writes his macro instruc- 
tions on the standard coding form, X28- 
6509, provided by IBM. For details regard- 
ing the use of this form and how these 
instructions are entered on the form, refer 
to the SEL publication IBM System/360 Model 
20^, Disk and, Tape„,Prograniiping Systems^ 
Ass em bl er_La n^uajg e , Form 024-90027 

Two types of macro instructions are 
required for the processing of the records 
in a logical file: one declarative macro 
instruction (referred to as file definition 
statement in this publication) and one or 
more imperative macro instructions. 

All imperative macro instructions con- 
sist of a mnemonic in the operation field 
and of one or more operands in the operand 
field. The precise format of the impera- 
tive macro instructions is shown separately 
for each of them later in this publication. 
The format of the definition statements is 
described under the heading Definition 
Statements below. 
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The input/output macro instructions pro- 
vided by IBM are presented in this section 
in the following groups: 



Figure 9 shows a summary of all DTFHT 
detail entries that are available to the 
user of the Model 20 ICCS. 

Figure 13 is a summary of all imperative 
macro instructions. The chart in Figure 13 
shows all allowable entries in the various 
fields of the IBM System/360 Assembler Cod- 
ing Form. 



DEFINITION_STATEMENTS 

The programmer must use definition state- 
ments to describe to the IOCS the charac- 
teristics of each file to be processed. 
Definition statements are used to assign a 
name to each of the user's input/output 
files, to describe the input/output device 
used for each file, to define the input/ 
output areas required, etc. The macro 
phase of the Assembler selects the routines 
required by the user on the basis of the 
definition statements given by the 
programmer. 

There are two types of file definition 
statements: DTFSE (Define The File in a 
SeEial type device) for card and printer 
files and DTFMT (Define The File on Magnet- 
ic Tape) for tape files. The user must 
write one DTFSE statement for each card and 
printer file to be used by the program. He 
must write one DTFMT statement for each 
tape file. 
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Figure 3. DTFMT Stateaent Followed by a DTFEM Statement 



A DTFEN statement (Define The Frle ENd) 
must follow the last definition statement 
of a given program. A DTFBG statement 
(Define The File BeGin) , if used, must be 
written as the first definition statement. 
If the Linkage Editor program is to be 
used, all the DTF statements must be con- 
tained in one and only one of the programs 
to be linked. 

The user must write his definition 
statements ahead of his problem program. 
If his program includes more than one DTFSE 
statement, the user must write his DTFSR 
statements contiguously, i.e., he is not 
permitted to write a DTFSR statement for 
one file followed by a DTFMT statement and 
a DTFSR statement for another file. 

Figure 3 is an example of a DTFMT state- 
ment followed by a DTFEH statement. 

A DTFSE or a DTFMT Statement consists of 
(1) a header entry that assigns a name to 
the file specified and (2) detail entries 
as required to define such information as 
the device to be used, the mode of proces- 
sing, etc. All DTFSR (DTFMT) statement 
cards, except the last one, must have a 
continuation punch in column 72. This con- 
tinuation punch may be any non-blank 
character. Punching in continuation cards 
must begin in column 16, except when the 
Assembler input format has been changed by 
means of an ICTL statement. 



DTFBG STATEMENT 

If DTFBG RWC=YES is specified, the IOCS 
provides the routines that make use of the 
read/compute, write/compute overlap fea- 
ture. All tape files will then be pro- 
cessed in the overlap mode. The statement 
has no name in the name field and must be 
written as the first definition statement. 



Note: This statement must not be used when 
no tape files are to be processed. 



HEADER ENTRIES 

A header entry consists of a file name in 
the name field (columns 1 through 8) and 
DTFSE (DTFMT) in the operation field 
(columns 10 through 14) . For the name 
entered in the name field, the same rules 
as for the Assembler apply, except as fel- 
lows: it must not exceed seven characters 
in length and the letter "I" as the first 
character is not permitted. 

The file name is used in imperative 
macro instructions that refer to the file. 



DETAIL ENTRIES 

A detail entry is 
immediately folio 
which, in turn, i 
cation. The leng 
limited to eight 
expressions with 
Expressions are p 
entries that regu 
comma must immedi 
cation of each de 
last one (see Fig 



I 



composed of a keyword 
wed ty an egual sign {=) 
s followed by one specifi- 
th of a specification is 
characters, including 
their operators (if any) . 
ermitted for all detail 
ire a symbolic address. A 
ately follow the specifi- 
tail entry, except the 
ure 3) . 



CADTICN: A blank within a detail entry 
specification causes the Assembler to con- 
sider the remaining characters of the spe- 
cification, and all subsequent detail 
entries of the DTFSR (DTFMT) statement, as 
comments. 

Together with the header entry, the 
detail entries describe the file and speci- 
fy symbolic addresses of routines and areas 
used when processing the file. This set of 
entries is used to generate the IOCS rou- 
tines for the file during assembly. 

Detail entries may be written (and 
punched) immediately after the header 
entry. They may appear in any order. The 
programmer must include only those entries 
that apply to a particular file. 
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The following sections describe all pos- 
sible detail entries for the DTFSR and the 
DTFMT statements. 



DTFSfi DETiilL ENTRIES 

The DTFSE detail entries are required to 
define card and printer files. They can be 
divided into five categories as follows: 

1. entries applicable for most files, 

2. additional entries for simple files, 

3. additional entries for combined files, 

4. additional entries for card printing, 
and 

5. additional entries for certain checking 
functions. 

£etail_Entries_f or_Most_Files 

The DTFSE detail entries applicable to most 
files are: 



DEVICE 
TYPEFLE 
WOEKA 
PEINTOV 



OVERLAP 
CONTROL 
BINABY 
EOFADDR 



The entries DEVICE, TYPEFLE, and WOEKA 
must be provided for each card and printer 
file to be used by the program. 

The entries PEINTOV, OVERLAP, CONTROL, 
BINABY, and EOFADDR must be provided only 
for certain card and printer files to be 
used by the program. 

• The PEINTOV entry must be provided for a 
printer file if a PETOV macro instruc- 
tion referring to the file is used in 
the program. 

• The OVERLAP entry must be provided for 
all files to be processed in non-overlap 
mode. 

• The CONTROL entry must be provided for a 
file if a CNTRL macro instruction refer- 
ring to that file is used in the 
program. 

• The BINARY entry must be provided for 
input files that are to be read in the 
column binary mode. 

• The EOFADDR entry must be provided for 
all input and combined files. 



DEVICE= 



This entry identifies the input/output 
device to be used to process the particular 
file. One of the following specifications 
must be entered immediately after the egual 
sign (=) following the keyword: 



CEP20 



MFCM1 



MFCM2 



PRINTER 



PRINTLF 



PEINTUF 



PUNCH20 



PDKCH42 



READ01 
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TYPEFLE= 



The file is to be read and/or 
punched by the IBM 2520 Card 
Read-Punch. 

The file is to be read and/or 
punched with or without card 
printing from the Primary Feed 
of the IBlf 2560 Kulti-Function 
Card Machine. 

The file is to be read and/or 
punched with or without card 
printing from the Secondary 
leed of the IBM 2560 Hulti- 
Function Card Machine. 

The file is to be printed by an 
lEB 2203 Printer with a stan- 
dard carriage or by an IBM 1403 
Printer (see Note below) . 

The file is to be printed on 
the lower carriage of an lEM 
2203 with the dual feed car- 
riage (see Hote below) . 

The file is to be printed on 
the upper carriage of an IBM 
2203 with the dual feed car- 
riage (see Note below) . 

The file is to be punched by an 
IBM 2520 Card Punch. 

The file is to be punched by an 
IBM 1442 Card Punch, Model 5. 

The file is to be read by an 
IBM 2501 Card Header. 
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This entry defines the type of the file 
{i.e., input, output, or combined). One of 
the following specifications must be used: 



INPCI 



for a simple input file 
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OOTPDT 
CHBWD 

HORKA=YES 



for a simple output file 
for a combined file. 



The HOHKA=YES detail entry is mandatory for 
all card and printer files. The user must 
enter the name of his work area as the 
second operand in his GET, PUT, and CBDPB 
macro instructions for the particular file 
and not in the HORKA entry for that file. 



PRINTOV=YES 

This entry must be included for a printer 
file if a PRTOV macro instruction referring 
to this file is used in the program. 



OVERLAP=NO 

This entry indicates that the file is to be 
processed in non-overlap mode. If this 
entry is omitted, the file is processed in 
overlap mode. Since printer files are 
always processed in the overlap mode, this 
entry is not permitted for these files. 

IOCS routines for overlapped processing 
require more (50- ICO bytes) main storage 
space than the routines for non-overlapped 
processing. 



CONTBOL=YES 

This detail entry is required if a CHTRL 
macro instruction will be issued for the 
file,. A CNTRL macro instruction causes the 
input/output device to perform operations 
such as stacker select and form skip. 



BINARY= 

This entry is required if the cards are to 
be read in the column binary mode. The 
entry may be provided for both simple and 
combined files. The specifications are: 



YES for simple files 
INPUT for combined files. 



The twelve punch positions of a card 
column read in column binary mode are 



stored in the 6 low-order bits of two adja- 
cent bytes of the input area. Therefore, 
the input and work areas must be specified 
to contain a number of bytes that is equal 
to twice the number of columns to be read. 

Khen the EIHiEY entry is used for a par- 
ticular file, the entries SEQNCE and 
EFCBKTn are not permitted for that file. 



EOFADDR=name 

This entry specifies the name of the rou- 
tine in the source program to which the 
IOCS should branch on an end-of-file condi- 
tion. In that routine, the user can per- 
form any operation required for the end of 
job, and he generally issues a CLOSE macro 
instruction. 

This entry is mandatory for input and 
combined files. 

The IOCS detects end-of-file conditions 
by sensing an end-of-file card with /♦ 
punched in columns 1 and 2. 

Additional Detail.. Entries_fgr_Sim2le_Files 

The entries described in this section are 
available for simple files only. One or 
mere of these entries may be required for a 
given file. The detail entries are: 

I0AREA1 
ICABEA2 
BLKSIZE 

ICABEA1=name 

This entry specifies the name of the input/ 
output area to be used by a simple file. 
This name must be the symbol used by the 
programmer in defining the area in his 
program. 

The ICAEEAI entry is not permitted fcr a 
printer file to be printed by the standard 
carriage. The printer uses the first 114 
main storage positions as a print buffer 
and they cannot be used by the progranmer. 

Two files printed by the dual feed car- 
riage require two I0ABEA1 entries, i.e., 
one for each file. The print areas for the 
lower and upper feed of the dual feed car- 
riage must be defined as contiguous areas 
in main storage with the print area for the 
lower feed preceding the area for the upper 
feed (see Figure ^} . 
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Lower-feed 
Print Area 



Upper-feed 
Print Area 



If two input/output areas are used for < 
file {I0AREA1 and I0AREA2) , only one 
BIKSIZE detail entry is required in the 
DTFSB statement for the file, and this 
entry applies to both areas. 

Kaxinum block lengths acceptable to the 
IOCS are as follows: 



I Address of 

I Lower-feed Area 



lAddress of 
IDpper-feed Area 



Figure 4. Print Area Format for Dual Feed 
Carriage 

Note that for card and printer files a 
work area must be specified in addition to 
an input/output area. Refer to the 
description of the WOEKA=YES detail entry. 

I0AEEA2=name 

This entry can be used to indicate the name 
of a second input area when the IBM 2501 
Card Reader is used in overlap mode. The 
name in the specification part of this 
entry must be identical with the symbol the 
programmer used in defining the area in his 
program. The area must be the same length 
as the area referred to in the I0AHEA1 
entry. 



The I0AEEA2 entry permits 
read into the area specified 
entry I0AREA1 while the data 
specified in the DTFSR entry 
the preceding card) is waitin 
into the work area. This may 
ficance, for example, if only 
selected cards of the file th 
the IBM 2501 require extensiv 
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If only one input area is spe 
data from a card that require 
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card reading speed of the IBM 
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This entry must not be used for a file 
being read or punched by any other card 
input or output device or when the IBM 2501 
is used in non-overlap mode. 

BLKSIZE=n 

This entry specifies the length of the 
input/output area(s) to be used by the 
file. The specification n must be equal to 
or less than the length in bytes of the 
reserved area. A ELKSIZE entry must be 
given for a printer file even though the 
I0AREA1 entry is not provided. 



1. 



2. 



gor_ card_.f iles : 
binary mode) . 



80 bytes (160 bytes 



Ior_£ri nter_ files : 120, 132, or lan 
bytes, depending on the number of print 
positions available. If a 2203 printer 
with the dual feed carriage feature is 
used, the total length of areas speci- 
fied for both feeds must be equal to or 
less than 114 bytes. 



The minimum block-length specifications 
are: 



1 • |o,r_in^ut files : 
binary mode) . 



Two bytes (four bytes 



2. For output files: One byte. 



Additional letail Entries f or C ombined 
Files 

The entries described in this section must 
be provided for each combined file. They 
are : 



INAEEA 
INBLKSZ 

INAREA=name 



CD AREA 
OUBLKSZ 



This entry is used to specify the name of 
the input area to be used by the combined 
file. This name must be the symbol used by 
the programmer in defining the area in his 
program. 

INBLKSZ=n 

This entry specifies the length in bytes of 
the input area to be used by the combined 
file. The length applies to the area 
defined in the main program and referred to 
in the INAREA entry. 

The maximum area length permitted is 80 
bytes (160 bytes binary mode). The minimum 
length is two bytes (four bytes binary 
mode) . 

CUABEA=name 

This entry specifies the name of the output 
area used by the combined file. The name 
must be the symbol used by the programmer 
in defining the area in his program. 
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OOBLKSZ=n 



This entry is used in conjunction with the 
OUAEEA entry to specify the length in bytes 
of the output area required by the combined 
file. The maximum block length permitted 
is 80 bytes. The minimum length of the 
output area is one byte. 



Column 16 



The following detail entries are only 
required if the card print feature of the 
IBM 2560 MFCM is to be used: 



CEDPBA 
CEDPRLn 



The two entries apply only to simple or 
combined files to be processed by the IBM 
2560 MFCM. 



The CBDPEA and CBDPBLn entries are 
required in only one DTFSB statement of a 
program as they do not refer to a particu- 
lar file. A CBDPB imperative macro 
instruction must be issued to cause the 
printing of data from the areas specified 
by the CBEPBA and CBDPBLn entries. Befer 
to the section CBDPB Macro Instruction. 



CRDPEA=name 

This entry is used in conjunction with 
CEDPELn entries when printing on cards is 
desired . 
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Figure 6. 



CEDPBA Detail Entry with CBDPBLn 
Entries 



4^ii t iona l„Detail_Ent rigs for _Card Printing CBDPBL n= m 



Figure 5. MFCM Card Print Areas 



Entries of this type are used in conjunc- 
tion with the CEEFBA=name entry to specify 
the print heads to be used. The keyword is 
CEDPELn, where n is the number of the print 
head. The specification m indicates to the 
IOCS the number of bytes to be printed by 
this print head. 

Eefer to the example in figures 5 and 6. 
In this example, print head 1 is to print 
the first 50 bytes of its 64-byte print 
area {part A) , print head 2 is to print the 
first 40 bytes of its 64-byte print area, 
and print head 5 is to print the first 20 
bytes of its 64-byte print area. However, 
all three print heads will print the first 
50 bytes of their 64-byte print areas. 
Therefore, the 64-byte print area for print 
head 2 in the example must contain blanks 
in bytes 41 through 50. Likewise, all 
bytes up to and including byte 50 of the 
64-byte print area assigned to print head 5 
would have to contain blanks if no printing 
were desired from print head 5 during a 
card print operation. 

The programmer need not be concerned 
about filling the unused byte positions of 
a print area with blanks as this is an 
automatic function of the IOCS. If, as in 
our example, 50 bytes is the largest number 
of bytes specified for one particular print 
head, the IOCS clears all print areas up to 
and including byte 50 to blanks after every 
card print operation. 

Specification of the number of bytes to 
be printed by each individual print head is 
required because, when filling a print area 
with data to be printed, the ICCS moves 
into the print area only the number of 
bytes specified for the particular print 
head. 

The programmer may utilize any unused 
portions of the print areas. In the 
example, bytes 5'1 through 64 of all three 
64-byte print areas could be used for other 
processing (shaded areas in Figure 5) . 

Additioi?al_Ietail_ Entries, for Checltin 9 
Functions 

The detail entries described below are 
available for card processing to enable the 
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user to specify certain checking functions. 



SEQNCE 
SEQXIT 
HFOHMTn 



RFXIT 

PFOBHTn 

PFXIT 



SEQNCE=xxyy 



This entry enables the programmer to check 
whether the contents of a specified field 
in successive input records are equal or in 
ascending order. 

If the input data is to be read in 
column binary mode, a SEQNCE entry must not 
be made for this file. 

The XX and yy are the numbers of the 
first and last card columns, respectively, 
of the card field to be checked. For card 
columns 1 through 9, the leading zero is 
required. Maximum length of the card field 
to be checked is 16 columns. 

Only one SEQSCE entry is permitted for 
each file. Sequence checking is accomp- 
lished by a logical compare operation. 

If the input cards are read in overlap 
mode from either an IBM 2520 or an IBM 
2560, a sequence error with a subsequent 
branch to the user's SEQXIT routine causes 
the IOCS to change the processing mode 
(from overlap to non-overlap) for the GET 
that detected the error. 

This change in the mode of operation 
enables the user to stacker-select the 
error card and/or to cause an error identi- 
fication to be punched into this card. 

Before branching to the user's routine, 
the IOCS places the record containing the 
field that led to the error condition into 
the work area. If the error card has been 
read by the IBM 2560 MFCM or the IBM 2520 
Card Bead-Punch, that card is positioned at 
the pre-punch station. The next GET or ECE 
macro instruction will cause the next rec- 
ord to be read. This record will then be 
compared with the record preceding the 
error record. 



sequence error occurs. To return to the 
main program, the programmer must provide a 
branch to the address contained in register 
14. after branching, the program executes 
the instruction following the GET that 
detected the sequence error. 

EF0EETn=xxyy2 

This entry enables the programmer to check 
whether a specified input card field (or 
fields) contain (s) numeric characters or 
all blanks. 

If the input data is to be read in 
column binary mode, an EJGBETn entry must 
not be made for this file. 

The keyword of this entry is EFCBMTn, 
where n is any number from to 9. The n 
position allows the programmer to write up 
to ten different EFCBMTn entries per file 
and thus have a maximum of ten fields 
checked. 

The XX and yy specify the first and last 
card columns, respectively, of the field to 
be checked. For columns 1 through 9, the 
leading zero is required. 

If the field is to be checked for 
blanks, z must be 0. If the field is to be 
checked for numeric characters, z must be 
1 . When checking for numeric characters, 
the maximum field length is 16 columns. 

When a field is tested for all blanks, 
the program branches to a user-written rou- 
tine (or causes a system halt) if the test 
fails. 

When a field is tested for numeric 
characters, the program branches (or causes 
a system halt) if the field contents are 
not of the following format (where at least 
the last character is numeric with or 
without an 11 or 12 zone punch): 



bbb, 



where 



b = blank 

n = numeric character. 



CAUTION: Do not destroy the contents of 
registers 14 and 15. Refer to the section 
Reg is ter Usage . 

If a SEQNCE error and an SFOEMT error 
are both detected in the same card, only 
the action specified for the SEQNCE error 
will be performed. 

SEQXIT=name 

This entry must be used in conjunction with 
the SEQNCE entry. It indicates the name of 
the entry point of the user's routine to 
which control is to be transferred when a 



If the input cards are read in overlap 
mode from either an IBM 2520 or an IBM 
2560, an EFCBMT error with a subsequent 
branch to the user's BIXIT routine causes 
the IOCS to change the processing mode 
(from overlap to non-overlap) for the GET 
that detected the error. 

This change in the mode of operation 
enables the user to stacker-select the 
error card and/or to cause an error identi- 
fication to be punched into this card. 

Before branching to the user's routine, 
the IOCS places the record containing the 
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field that led to the error condition into 
the work area. If the error card has been 
read by the IBM 2560 MFCM or the IBM 2520 
Card Bead-Punch, that card is positioned at 
the pre-punch station. The next GET or ECM 
macro instruction causes the next record to 
be read. 



CAUTION: Do not destroy the contents of 
registers 14 and 15. Refer to the section 
J e J is_ter_ Us a^ € . 



The progranmer may use up to ten dif- 
ferent BFOEMTn entries, but only one EFXIT 
entry for each file. 

If a SEQNCE error and an RFOEMTn error 
are both detected in the same card, only 
the action specified for the SEQNCE error 
will be performed. Refer to the descrip- 
tion of the SEQNCE=xxyy detail entry. 



RFXIT=name 

This entry is used in 
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If this entry is omitted and the test is 
negative, a programmed halt occurs. This 
enables the operator to replace the card 
that led to the error condition. 

PFOEMTn=xxyy 

This entry enables the programmer to check 
those cards of a combined file that are not 
read into a work area by GET macro instruc- 
tions to ensure that a specified card field 
(or fields) to be punched contains blanks. 

The keyword of this entry is PFORMTn, 
where n is any number from to 9. The n 
position allows the programmer to write up 
to ten different PFORMTn entries per file 
and thus have a maximum of ten fields 
checked. The xx and yy specify the numbers 
of the first and last card columns, respec- 
tively, of the field to be checked. For 
columns 1 through 9, the leading zero is 
required. 

If the field is found not to contain all 
blanks, the PUT macro instruction is not 
executed. Instead, either control is 
transferred to a user-written routine (pro- 



vided the branch address has been furnished 
by a EFXIT detail entry) , or a programmed 
halt occurs. 



CAUIICN: Co not destroy the contents of 
registers 14 and 15. Refer to the section 
Jec[is te r_ Us age . 



The specified input area must be large 
enough to permit the program to read the 
information in the columns specified in 
this entry into main storage. 



The programmer may use up to ten dif- 
ferent PFORMTn entries, but only one PFXIT 
entry for each file. 



PFXIT=name 



This entry is used in conjunction with the 
PFORMTn entry. It indicates the name of 
the entry point of the user's routine to 
which control is to be transferred if the 
test on the field specified ty the PFOBMTn 
entry fails. To return to the main pro- 
gram, the programmer must provide a branch 
to the address contained in register 14. 
after branching, the program executes the 
instruction following the PUT that detected 
the EFOEMTn error. 



If a PFORMTn check occurs, the program 
branches immediately to the user's routine. 
In this case, the contents of the work area 
are not moved to the punch area. 

If a PUT macro instruction is given that 
refers to a combined file and the program 
branches to the PFXIT routine, a subsequent 
GET will place the contents of the card 
causing the PFOEMT error into the work 
area. If this GET is in non-overlap mode, 
it is possible to punch this card by means 
of an additional PUT macro instruction. 



If the PFXIT entry is omitted and the 
test shows an error condition, a halt 
occurs before punching is initiated. This 
enables the operator to replace the card 
that led to the error condition. That card 
is positioned at the pre-punch station. 



DTFMT DETAIL ENTRIES 

DTFMT detail entries apply to tape files 
only. Although many of thea are identical 
with DTFSR detail entries, all possible 
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DTFMT detail entries are described in this 
section in this order: 



VARBIK for variable length blocked records 



TYPEFLE 

DEVaCDE 

BECFOEH 

EECSIZE 

FILAEL 

LABADDE 

EEEOPT 

WLEEBE 

EEEIO 

EOFADDR 

I0ABEA1 



I0AREA2 

lOBEG 

WOBKA 

BLKSIZE 

CONTROL 

VAEBLD 

ALTTAPE 

EEAD 

SEKINE 

TPMAEK 

CKPTEEC 



UKDEF 



for undefined records. 



TYPEFLE= 

This entry defines the type of the file 
(i.e., input or output). The allowable 
specifications are: 



INPUT 
OUTPUT 

DEVAEDE= 



for an input file 
for an output file. 



This entry defines the symbolic address of 
a tape drive to be associated with the par- 
ticular file. The following symbolic 
addresses are permitted: 

SYSIPI 
SYSOPT 
SYSnnn 

where nnn may be any number 
from 000 to 015. 

An actual tape drive address is assigned 
to the symbolic address by means of an 
ASSGN control statement that is processed 
either (a) by the Job Control program 
before the problem program is executed, or 
(b) at the time of system generation. 
Befer to the SEL publication IBM_S^stem^36C 
M ode l 2 p,t_Tape. Programming System, Control 
and Service Programs , Form C21-9000. 



BECFOEM= 

This entry defines the record format of the 
file. The IOCS can handle different types 
of records in the same program. However, 
the records in a file must be of the same 
type. The following specifications are 
possible: 

FIXUNB for fixed length unblocked records 

FIXBLK for fixed length blocked records 

VAEUNB for variable length unblocked 
records 



If the EECFOEM entry is omitted, fixed- 
length unblocked records are assumed. 



When variable-length records are speci- 
fied for a tape output file, the user's 
input/output area must include four addi- 
tional bytes in which the block-length in- 
dication is built. If these records are 
unblocked, the four additional bytes are 
used to develop the length indication for 
each record (as each record is handled the 
same way as a block) . If these records are 
blocked, the four additional bytes are used 
to develop the length indication for the 
entire block. 



EECSIZE= 

This entry applies to tape files containing 
either fixed length blocked records or 
undefined format records. 

n is specified to indicate the number of 
bytes in an individual record for a 
tape file containing fixed length 
records. 

(n) is specified to indicate a register if 
the file contains record of undefined 
format. 

The IOCS uses the specified register 
to (1) provide the record size in case 
of an input file or (2) derive from it 
the record size in case of an output 
file. For output files, it is the 
user's responsibility to place the 
number of bytes contained in a record 
into the specified register before 
this record is written. 

If a file containing records of unde- 
fined format is to be read backward, 
the contents of the specified register 
must be used to determine the begin- 
ning of each individual record. 

The specification is either the number 
of the desired register (any one of 
the numbers 8 through 13) , or a symbol 
that stands for this register, in 
parentheses. (If the user's problem 
program contains IOCS macro instruc- 
tions that refer to the IBM 1259 or 
1419 Magnetic Character Eeaders, reg- 
isters 11 and 12 must not be used.) 

The minimum and maximum record lengths 
permitted are as shown below. Lengths 
are given in number of bytes. 



Macro Instructions 19 



Record Type 



flXUME 
FIXBLK 



VAIUNE* 
VARBLK* 



DNDEF 



nininuDi 



I Haxinui 
H 1 



Input 1 Output I Input 1 Output | 

18 I 18 I U095I 4095 | 
4 -I ^ ^ 

1 I 18 1 a095l 40S5 1 
+ ^ 4 ^ 1 

I 14 I 40911 '*091 I 
4 -I ^ 

1 14 1 40911 4091 I 




I 18 1 40951 4095 | 
J 1 1 

* Excluding the four bytes required fori 
record length indication. I 

FILABL= 



This entry indicates the type of label pro- 
cessing to be performed. The allowable 
specifications are: 

STD for a tape input file, if standard 
labels are to be checked; or for a 
tape output file, if IBM standard 
labels are to be written. 

NSTD for input files only, non-standard 
labels are skipped. The labels 
must be terminated by a tape nark. 

NSTE may also be specified for a 
tape input file with IBM standard 
labels if these labels are not to 
be checked. 

NO is specified if no labels exist. 

Notei If FILABL=NO is specified 
for an output file, any existing 
volume label on the output tape 
will be overwritten. 



The FILAEL entry may be omitted for an 
unlabeled tape. 



by the identification in the label itself. 
For an output file, register 8 contains one 
of the following codes: 

'bO'- for a header label (when a file is 
opened) , 

'bF'- for an end-of-file label (on an end- 
of-file condition) , 

' b V - for an end-of-volume label (on an 
end-of -volume condition) . 

where b=blank. 



Register 9 contains the address of the 
IOCS label area at the time the user's rou- 
tine is being entered. 

At the end of a LAEAIEE routine, the 
programmer must issue an LBRET macro 
instruction to return control to the IOCS. 
Refer to LBRET ,M.acrg_ Ins true t io n . 

CAUTION: Do not destroy the contents of 
registers 14 and 15. Refer to the section 
E e^is t er_ Us aje . 



EIECE1= 

This entry applies to tape in^ut files; it 
specifies functions that are to be per- 
formed when an error block is detected. 

Khen the Easic Konitor program detects 
an error in a block of input records, the 
tape is backspaced and reread 100 times 
before the block is considered to be an 
error block. Unless the EEBCPT entry is 
included, which specifies procedures to 
fellow in the event of an error condition, 
a halt occurs and the job is terminated. 
Either IGNORE, SKIP, or the symbolic name 
of an error routine can be specified in 
this entry. One of these specifications is 
entered immediately after the = sign in the 
keyword. The functions of the three speci- 
fications are: 



I 
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For an input file, the user can deter- 
mine the type of label that has been read 



IGNORE The error condition is completely 
ignored, and the records are made 
available to the user for 
processing. 

SFIE The block containing the error is 
skipped, i.e., it is not made 
available for processing. The next 
block is read from tape and proces- 
sing continues with the first rec- 
ord of that block. 

name The IOCS branches to a user-written 
error routine which can perform any 
chosen error procedure, for 
example, listing the error 
condition. 
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In his routine, the programmer must 
not issue any GET macro instruc- 
tions for records in the error 
block. If he uses any ether IOCS 
macros in his routine, he must save 
the contents of registers 1U and 
15. at the end of his routine he 
must return to the IOCS by branch- 
ing to the address in register 14. 
When control is returned to the 
problem program, the first record 
of the next block is available for 
processing in the main program. 
When two input/output areas are 
used, and EfiRIO=name is specified, 
the address of the input/output 
area containing the error block is 
placed in the location indicated by 
the symbolic name in the EERIO 
entry. Register 14 contains the 
return address. 

Note: If FILaBL=STD is specified, the 
error block is always counted in the 
block count. 

The entry applies to wrong-leiAgth rec- 
ords if the CTFHT entry WLRERE is not 
included. 



WLEERE=name 

This entry applies only to tape input files 
that do not contain undefined records. It 
specifies the symbolic name of a user's 
routine to which the IOCS branches if a 
wrong-length record is read. In his rou- 
tine the user may perform any operation he 
desires for wrong-length records. However, 
he must not issue any GET macro instruc- 
tions for this file. If he uses any other 
IOCS macros in his routine, he must save 
the contents of registers 14 and 15. 

It the end of his routine the user must 
return to the IOCS by branching to the 
address in register 14. When control is 
returned to the problem program, the first 
record of the next block is available for 
processing. 

When two I/O areas are used, and ERRIO= 
name is specified, the address of the I/O 
area containing the wrong-length record is 
placed in the location indicated by the 
symbolic name in the ERRIO entry. Register 
14 contains the return address. 

Whenever fixed-length blocked records or 
variable-length records are specified 
(RECFORM=FIXBLK, =VARUNB, or =VARBLK) , the 
machine check for wrong-length records is 
suppressed and the IOCS generates a pro- 
grammed check for record length. For 
fixed-length blocked records, the record 
length is considered incorrect if the block 
that is read is not an integer multiple of 



the record length (specified in the RECSIZE 
entry) , up to the maximum length of the 
block (specified in the ELKSIZE entry) . 
This permits the reading of short blocks of 
records without a wrong-length-record 
indication. 



For variable-length records, record 
length is considered incorrect if the 
length of the physical record (block) is 
not the same as the block length specified 
in the first two bytes of the block. 
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Bote that the IOCS does not provide to 
the user the number of bytes contained in 
the wrong-length record. 

If the KLEEEE entry is omitted from the 
set of DTFMT entries, but a wrong-length 
record is detected by the ICCS, one of the 
following results: 

1. If the ERECIT entry is included for 
this file, the wrong-length record is 
treated as an error block and handled 
according to the user's specifications 
for an error (IGHCEE, SKIP, or name of 
error routine) . 

2. If the EEROPT entry is not included, 
the job will be terminated since no 
error recovery procedure is available 
to handle the wrong-length record. 

ERRIO=name 

This entry specifies the symbolic name of a 
two-byte area, in which the IOCS places the 
address of: 

1. The input area containing the block 
that caused an irrecoverable read error 
(if the name of the user's error rou- 
tine is specified in the ERRCPT entry), 
or: 

2. The input area containing the wrong- 
length record (if the name of the 
user's wrong-length record routine is 
specified in the WLRERR entry) . 

If READ=BACK is specified, the address of 
the input area plus the specified ELKSIZE 
minus 1 (in other words, the last byte of 
input the input area) is inserted in the 
two-byte area. 
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This entr^ aay only be issued if EBROPT= 
name, and/or HLaEBH=name, and two I/O areas 
are specified. 

Hote: Befer to the descriptions of the 
detail entries EBBOPT= and WLBEBB=naBe. 

EOFADDB=name 

This entry is mandatory for all input 
files. It specifies the name of the rou- 
tine in the user's program that the IOCS 
should branch to on an end-of-file condi- 
tion. In that routine, the user can per- 
form any operation required for the end of 
job, and he generally issues a CLOSE macro 
instruction. However, the user must not 
issue a GET macro instruction in his 
EOFADDB routine since no further records 
are available for processing. 

An end-of-file condition is detected by 
reading a tape marX and EOF in the trailer 
label when standard labels are specified. 
If standard labels are not specified, the 
Model 20 IOCS assumes an end-of-file condi- 
tion when it reads a tape mark. 

ICABEA1=name 

This entry specifies the name of the input/ 
output area to be used. This name must be 
the symbol used by the programmer in defin- 
ing the area in his program. 

If the record format is variable length, 
four bytes of the input/output area must be 
reserved for the block size field. In 
addition, the input/output area must be 
defined at a half-word boundary. Refer to 
Ingut/Output-Hork. Area Combinations. 

I0AEEA2=naroe 

Two input, or output, areas can be speci- 
fied for a tape file, to allow data trans- 
fer to be overlapped with processing. In 
such a case, I0aREA2=name must be included. 
This operand specifies the symbolic name of 
the second I/O area; this name must be 
identical to the name used in the DS or DC 
statement defining the area. 

The length of the second I/O area must 
be equal to the length of the first I/O 
area. The second I/O area must be defined 
by the programmer at a half-word boundary. 

A warning message (MNOTE) is given on 
the printer if I0ABEA2 is specified without 
DTFBG RWC=YES being the first definition 
statement. (Refer to In^ut/Output-jjork 
Area Combinations.! 

IOEEG= (n) 

This entry specifies a register. The spe- 
cification is either the number of the reg- 



ister (any one of the numbers 8 through 13) 
or a symbol that is equated to the regis- 
ter, between parentheses. 

Note: If the user's problem program con- 
tains IOCS macro instructions that refer to 
the lEH 1259 or 1419 Magnetic Character 
Readers, registers 11 and 12 must not be 
used. 

An ICBEG entry is reguired when: 

1. blocked input or output records are 
processed in the input/output area, or 

2. variable-length unblocked records are 
read backward and are processed in the 
input area, or 

3. two input, or output, areas are used 
and the records (either blocked or 
unblocked) are processed in the input/ 
output area. 

The specified ICBEG register contains: 

1. for an input file, the address of a 
logical record available for 
processing, 

2. for an output file, the address of an 
area that is available to the user for 
building the next record. 

HCRKA=YES 

If the user desires to process the records 
of a file in a work area rather than in the 
input/output area for the file, he must 
include the WOEKA=YES entry and establish 
the work area(s) in main storage. The name 
of the work area is entered as the second 
operand in GET (EUT) macro instructions for 
the particular file. Input/Output areas 
for tape files must not be used as work 
areas. For further information about the 
use of a work area, refer to the section 
I n p u t /'Q u t E u t- Hg r k ,. A r e a _ Co p b i nations . 

If WCEKA=YES is specified for an output 
file containing variable-length records, 
the programmer must define the work area (s) 
at a half-word boundary. 

BLKSIZE=n 

This entry specifies the length of the 
input/output area. The specification n 
must be equal to the number of bytes of a 
block. If the record format is variable, 
the specified length must be equal to the 
number of bytes contained in the longest 
block of records. 

The maximum block length acceptable to 
the IOCS is 4095 bytes which is equal to 
the maximum block length for IBM 2415 
tapes. The minimum block length is 18 



22 IBM System/360 Model 20 TPS IOCS 



bytes, except for tape input files contain- 
ing checkpoint records. For these tape 
files, the rainimum area length is 20 bytes. 

Note: A message (MNOTE) is given on the 
printer if the BLKSIZE entry in the DTF 
statement specifies a blccklength of less 
than 18 bytes, or if the BECSIZE entry spe- 
cifies a record length of less than 18 
bytes for output files, and less than 1 
byte for input files (See also the table at 
the end of section RECSIZE=) . Generation 
is then terminated. 

If variable-length unblocked records or 
records of undefined format are to be pro- 
cessed in a work area, the programmer 
should consider the following: A GET 
causes the IOCS to move the number of bytes 
specified in the BLKSIZE detail entry from 
the input area into the work area; a PUT 
causes the IOCS to move this number of 
bytes from the work area into the output 
area. Therefore, the programmer must, for 
an output file, ensure that the address of 
the work area he uses is equal to or lower 
than the upper main storage limit minus the 
BLKSIZE value. 

CONTEOL=YES 

This detail entry is required if a CNTEL 
macro instruction will be issued for the 
file. A CNTEL macro instruction causes the 
associated tape drive to perform operations 
such as tape rewind, rewind and unload, 
backspace, etc. 

VABBLD=(n) 

This entry is necessary if an output file 
with variable-length blocked records is 
being processed and no work area is speci- 
fied. This entry specifies a register that 
indicates the number of bytes in the output 
area available for building the next 
record. 

The specification is either the number 
of the desired register (any one of the 
numbers 8 through 13) , or a symbol that 
stands for this register, in parentheses. 
{If the user's problem program contains 
IOCS macro instructions that refer to the 
IBK 1^19 Magnetic Character Reader, regis- 
ters 11 and 12 must not be used.) 

After a PUT macro instruction is issued 
for a variable length record, the space 
still available is calculated and placed in 
the VAEELD register. The user then com- 
pares the length of his next record with 
the available space. If the record will 
not fit, the user must issue a IfiUNC macro 
instruction to cause the completed block of 
records to be written on the tape file. 
Then the present record is placed into the 
beginning of the output area and becomes 



the first record in the next block. For 
information regarding the PUT and the TEUHC 
macro instructions, refer to the sections 
P J T_eacro_ Inst ruction and TEUH C Macro 
ill§t£uc t io n . 

ALTTAPE= 

This entry specifies the symbolic address 
of a tape drive that is to be used as an 
alternate drive when a tape file is con- 
tained in two or more reels (volumes) . The 
physical tape drive address can te assigned 
to the specified symbolic address either at 
the time of system generation or by means 
of an assign (ASSGN) statement that is used 
by the Job Control program. The user can 
specify one of the following: 

SYSIPT 
SYSCET 
SYSnnn 

where nnn may be any number from 
000 to 015. 

If the physical tape-drive address is 
assigned to the specified symbolic address 
by means of an ASSGH statement, the second 

(fourth, sixth, etc.) reel of tape may be 
mounted on any one of the tape drives that 
are attached to the system and available. 
The selected tape drive is assigned to the 
specified symbolic address. The first 

(third, fifth, etc.) reel of tape would 
then be mounted on the tape drive specified 
in the BEVAEDE entry of the ETFMT statement 
for the file. 

The method described above allows suffi- 
cient time for the operator to mount the 
third reel on the tape drive specified in 
the DEVfiEEB entry while the records on the 
second reel are processed. He can mount 
the fourth reel on the tape drive specified 
in the ALTTAPE entry while the records on 
the third reel are processed; and so on. 

Ihe ALTTAPE detail entry may te speci- 
fied for input and output files. If speci- 
fied for an output file, the ICCS switches 
the tape drives in accordance with the ALT- 
TAPE specification on detection of an end- 
of-volume condition, i.e., when the reflec- 
tive marker at the end of the tape is 
sensed . 

If the entry is specified for input 
files, the functions of the ICCS vary 
depending on the type of labels (if any) 
specified for the file. 

1- iian3ard_Iabels^ The ICCS switches the 
tape drives in accordance with the ALT- 
TAPE specification. 

2. Icn-Standard_and_No_LabelSj, The ICCS 
has no means of determining the end of 
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Not e : ALTTAPE may not be specified when 
READ=flACK is specified. 



READ = 

This entry specifies the direction in which 
an input tape is to be read. If this entry 
is omitted, IOCS assumes forward reading. 

FORHABD is specified for a tape to be read 
in the normal forward direction. 



BACK 



is specified for a tape to be read 
backward. However, READ=BACK can- 
not be specified: 

1. for tape input files contain- 
ing variable-length blocked 
records, 

2. when ALTTAPE is specified. 



REWI1SIB= 



This entry is used to specify the desired 
rewind and unload operation when an OPEH or 
a CLOSE macro instruction is given or when 
an end-of-volume condition is sensed. 

UNLOAD is specified to rewind the tape 
when an OPEN macro instruction 
is given and to rewind and 
unload the tape when a CLOSE 
macro instruction is given or 
an end-of-volume condition 
occurs. 

NCRWD is specified if no rewind is 

desired. This entry is manda- 
tory if READ=BACK is specified 
for the file. 

If this entry is not included, an OPEN 
or CLOSE macro instruction or an end-of- 
volume condition causes the tape file to be 
rewound, but not unloaded. 

TPMAEK=NO 

This entry applies only to unlabeled tape 
output files (FILABL=NO). If included, 
this entry will prevent the writing of a 
tape mark as the first record on a tape. 
If this entry is not included, a tape mark 
will be written as the first record. 



CKPTBEC=XES 

This entry is required if a tape input file 
contains checkpoint records interspersed 
among the data records. Hhen this entry is 
provided, the IOCS recognizes and bypasses 
checkpoint records. 

lape files created by the Hodel 20 IOCS 
programs will not contain any checkpoint 
records. Therefore, this entry is only 
required when it is desired to read from a 
magnetic tape that was written by use of 
another program and contains interspersed 
checkpoint records. 

If the CKPTREC detail entry is specified 
for a tape input file, the programmer must 
specify a block size (BLKSIZE entry) of at 
least 20 bytes, which is the minimum length 
of a checkpoint record. 

A group of checkpoint records is identi- 
fied by a header and a trailer identifier, 
each of which contains the characters 
///bCHKETb// (where b = blank) . The user 
must ensure that ,none of his input blocks 
contains this character combination in the 
first twelve positions. 



DTFEN STATEMENT 

A DTFEN (Define The File ENd) statement 
must follow the last defining (DTFSR or 
DTFKI) statement. A ITJEN statement con- 
sists of DTFEN in the operation field, the 
name field is left blank. The operand 
field may be left blank or it may have 
C\LA1 (overlay) specified to reduce the 
amount of main storage used for the 
program. 
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Shen CVLAX is specified, the OPEN and 
CLOSE input/output routines for tbe usei'i 
tape f ile (s) are not generated as part of 
the ETF routines. Instead, they are 
generated in-line, i.e., when the first (or 
only) OPEN (or CLOSE) macro instruction for 
a tape file is encountered by the 
Assembler. 

It is not sufficient, however, to speci- 
fy CVIAI in the ETEFN statement in order to 
have the OVLAY function performed. In 
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addition, the programmer must observe the 
following (refer to Figure 7) : 

1. Write all user-written label handling 
routines, including those needed when 
closing a file (or files) , ahead of the 
first OPEN macro instruction. 

2. Position all literals required by these 
label routines ahead of the first OPEB 
macro instruction. This is accomplished 
by means of an LTOBG Assembler 
instruction. 

3. Open all tape files before the OPEN rou- 
tines are overlaid by the problem 
program. 
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The routines used to open files (and 
additional volumes of multi-volume 
files) are not available after they have 
been overlaid. Therefore, OVLAY can not 
be specified in programs that process: 

a. multi-volume tape files, and 

b. multi-file tape reels if more than 
one file on the tape is used. 

U. Initiate execution of the OPEN macro 
instruction by a subsequent XFR state- 
ment (XFR BEGIN in Figure 7) which may 
or may not immediately follow the OPEN 
macro instruction. A FETCH macro 
instruction (FETCH ROUTIN in Figure 7) 
must be given following the last OPEN 
macro instruction. This FETCH causes 
part or all of the user's program to be 
loaded. 

5. Give an ORG statement (ORG BEGIN in 
Figure 7) immediately after the XFR 
statement. The operand of this ORG 
statement specifies the address where 



the overlay is to start and may be the 
same as the name of the OPEN macro 
instruction. 

For details concerning the FITCH, XFR, 
and ORG statements, refer to the £BL 
publications I J fi_ S^s t e m/ 3 6 0_ Mo d e 1_ 2 0^ 
J^£g.-£lo3J3Lmming_Systemj,_ Control and 
JjiJ vic€_ Program s / form C21-9C00, and IBM 
Syst§m/360 Kgdel 20f„, £ isk and Tape Pro- 
gr a ami ng gjs t emSjt_ Ass e m bl €r_ L a n^ u ajg e , 

Form C24-9002, 

6. Ose XFE and ORG-statements (XFR HODTIN 
and ORG xxxx in Figure 7) just prior to 
the CLOSE macro instruction. The 
operand of the ORG statement specifies 
an address in the preceding problem pro- 
gram. As in the case of the CPEN macro 
instruction, only one CLOSE macro 
instruction for all files should be 
given. 

7. Issue a FETCH macro instruction (FETCH 
FINIS in Figure 7) for another program 
segment (i.e. another part of the pro- 
gram) . This segment would include the 
routines that have been generated for 
the CLOSE and EOJ macro instructions. 
The loading of this segment begins at 
the address specified as the operand of 
the ORG statement preceding the CLCSE 
macro instruction. 

Steps 1 through 5, above, cause some or 
all of the coding between the location 
indicated by the operand of the first ORG 
statement (BEGIN) and the next XFR state- 
ment (XEF BEGIN) to be overlaid by the pro- 
blem program. steps 6 and 7 cause the 
overlaying of part or all of the problem 
program by the CLOSE and end-of-job 
routines. 

J]SEJ-KBITTEN_i3ACB0_ElJIJITiCN. If the pro- 
grammer writes his own macro definitions, 
the following restrictions apply: 

• The global SETB symbol SBG69 must not be 
used if the program includes IOCS macrc 
definitions. 

• The global SETB symbols 6EG72 through 
SBG77 must not be used if the program 
includes 1259 or 1419 ICCS macro 
definitions. 

• The global SFTE symbols 8EG1 through 
SEG19 must not be used if the overlay 
programming technique is used. 
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START 
DTF 



DTF 



DTFEM 



LAEADR — 



BEGIN 



OPEN 



OPEN 



OVLAI 

Generated EOF and EOV 
routines 

User label handling 
routines 

Problem program 
initialization 

tapefle^ tapefle 

Generated OPEN routine 
for tape file (s) 



tapefle 

Generated linkage (to 
OPEN routine) 



FETCH ROUTIN 
XFR EEGIN 



ORG 
ROUTIN 



BEGIN 



1 



OPEN cardfle 

Generated linkage (to 
DTFSR routine) 



WAITC 

FETCH FINIS 



XFR 



ORG 

FINIS CLOSE 



EOJ 
END 



ROOTIN 
xxxx 

FINIS 



Note: At the end of generation of DTFEN, 
the global set symbols 6BG1 through SBG68, 
6BG95 and &EG128 are set to zero ty the 
IOCS (SBG1 through 8EG19 and eEG69 are only 
reset if overlay has not been specified) . 



l£SIGHJENT_CF_EiSl_ 
OPEN and CLOSE inpu 
generated in line, 
sider their approxi 
ing and loading the 
program. For infor 
these routines, ref 
tion IBJ_Si£tem2:360 
jin5_Sxstem^_Perfor 
C24-9010.~~ 



I JG IS T E RS . 
t/output rou 
the programm 
mate sizes w 
base regist 
mation on th 
er to the SR 
_Hodel_iO^_T 
mance Estima 



Since the 
tines are 
er must con- 
hen assign- 
ers for his 
e sizes of 
L publica- 
ape Pr ogram- 
tes. Form 



J AS E_ EEGI ST E R_9 . When EFTEN OVLAY is spe- 
cified the routines for the processing of 
the IBM standard labels VCI1 and HEE1 are 
generated as part of the OPEN routines 
instead of as part of the ETF routines. At 
the end of these label processing routines, 
the Assembler instruction EECP 9 is 
generated. If the user has given a USING 
instruction for register 9 at the beginning 
of his program, he must repeat this 
instruction immediately after the OPEN 
macro instruction. Reloading the register 
is not required because its contents is 
restored to the value that was contained in 
the register before the execution of the 
CPEK macro instruction. 



Figure 7. Coding for File Processing Using 
the Overlay Programming 
Technique 
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Opera- 
tion 

DTFSR 



h 



Keyword 



EINABY 



ELKSIZE 



CONTROL 



Operand | 

2520 
256 Ci Bead- 
Punch 



Applies to 



Allowable 
Specifications 



-4— 



YES 



4 



INPUT 



+— 

length of sim- 
ple file input/; 
output area 
in bytes 



YES 



X* 



4 



X* 



+ + — 



2520 
Punch 



1142 
Kod 5 
Punch 






X 



+ + 



2501 



+- 



2203 



Always first 
card/ may include 
detail entries 
from column 16 
to column 71. 



1403 



—4 

Indicates length 
of area speci- 
fied by ICABEA1 - 
I0ABEA2 entries. 

X IReguired if a 
CKTEL macro is 
given for a file. 



Eemarks 



♦ Only for 

simple files. 
-j 4_. 



Only for com- 
bined files. 



-^ 









Figure 8. Definition Statement Summary for Card and Printer riles. Part 1 of 3 
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Opera- 
tion 
k " 



H- 



h 



Operand 



Keyword 
CRDPRA 



h 



J. 



CEDPELnl length of card 
print area in 
bytes 

HFCM 1 



DEVICE 



READ01 

1 

PRINTER 



PEINTLF 
PRINTUF 



EOFADER 



+ 

IN ARE A 



IHELKSZ 



lOiHEAl 



I0AREA2 



OUfiHEA 



+ + 

OUBLKSZ 



Allowable 
Specifications 



-T 

I Applies to 

"T 1 ' 1 



name of user- 
defined card 
print area 



-4- 



HFCM 2 
CHP20 



PDNCH20 



— 4 



PUNCH42 



-+ 









name of user's 

end-of-file 

routine 



name of 
combined file 
input area 



length of com- 
bined file in- 
put area in 
bytes 



name of the 

user-defined 

area 



name of the 

user-defined 

area 



— 4 



— 4 



name of 
combined file 
output area 

length of com- 
bined file out- 
put area in 
bytes 



256C 



~4 






X* 



2520 
Read- 
Punch 



X* 



4 

X 



2520 
Punch 









+ 



1- 



11*42 

Kod 512501122031 14031 Remarks 

Punch 

4 



4 4 4 ^ 



+ 4 4 

X 



4 



-4 



4 4 

X 



4 4 



4 

X 



4 

X 



4 



4 4 



—4 -! 



4 4 



4 ^ 



4 4 



4- 



X 

4 



4 

X* 



4 



4 



— 4 






— -\ 



4 






4 



4 



--4 



4 



n in the keyword 
is a printhead 
number. 



For 2203 with 
dual-feed- 
carriage. 



♦ Only for in- 
put and/or 
combined files. 

Combined files 
only. 



Combined files 
only. 



♦ Entry required 
for 2203 only 
when dual-feed- 
carriage used. 



Can be used if a 
2501, Model Al, 
is used in over- 
lap mode. 



Combined files 
only. 



Combined files 
only. 






Figure 8. Eefinition Statement Summary for Card and Printer Files, Part 2 of 3 
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h 



I 



I Operand | 



Applies to 



Opera- 
tion 



CVEBLAP 



PFORMTn 



+ 



+ 






Keyword 



PFXIT 



name of user 
routine used 
when FFOEHTn 
test fails 



PEINTOV 






SFORMTn 



EFXIT 



SEQNCE 



SEQXIT 



TYPEFLE 



WOBKA 






Allowable 
Specifications 



NO 



2560 
4 

X 



4 



xxyy 



YES 



-4 



xxyyz 






--+ 



name of user 
routine used 
when EFOEMn 
test fails 






xxyy 



+ 



name of user 
routine used 
when SEQNCE 
test fails 



4 



INPUT 



OUTPUT 
CMBND 



YES 



.+ 



252C 
Eead- 
Punch 
+ 

X 



X 

+ 

X 



252C 
Punch 



14ii2 
Mod 5 
Punch 
+ 1- 

X 



4- 

X 






+ 

X 



25C1 



1 

If omitted, file 
is processed in 
overlap mode. 

Indicates that a 
check for blanks 
is to te made of 
field from col xx 
to yy prior to 
punching. 



f 



X 

■ + + 

X 

4 4 



+ 

X 



2203 



4 



4 



4 



4 

X 

4 



r -f 

1403 



+ 



X 

H 



Bemarks 



Beguired if a 
PBTCV macro is 
given for the 
file. 

Indicates that a 
check for numer- 
ics or blanks is 
desired from 
col XX to yy in 
input cards. 



Indicates sequence 
check of input 
cards desired from 
col XX to yy. 



Kust be speci- 
fied when 
SEQKCZ is spe- 
cified. 






Mandatory for 
all card and 
printer files. 



Figure 8. Definition Statement Summary fcr Card and Printer Files, Part 3 of 3 
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CONTBOL 
DEVADDfi 



Opera- 
tion 

DTFMT 



I Operand 



1- — 



Keyword 



ALTTSPE 



SYSIPT 

1 

SYSOPT 
I 

SYSnnn 



BLKSIZE 



CKFTHEC 



EOFfiDER 



1 SYSIPT, SYSOPT and SYSnnn are symbolic addresses to be 

^used when processing tape files. 

SYSOPT I 

J ^ 

SYSnnn 1 

name of user |For input files only, 
end-of-file | 



EREIC 



EBROPT 



FILflEL 



lOARZai 



^ + 

I0AREA2 



Allowable IRemarks 
Specification | 

f 



i Applies to tape files only. 
-4- 



JReguired for multi-volume files using two tape drives. 
"I SYSIPT, SYSOPT, and SYSnnn are symbolic addresses to be 
jused when processing tape files. 



length of file | Length of I0AEEA1 as defined in main program, 
input/output I 
area in bytes | 

1 



YES 



IHeguired to read tapes containing interspersed 
jcheckpoint records. 



YES 
SYSIPT 



1 Required if a CNTBL macro is given for the file. 



H 



routine 



name of a two- JMay only be specified if the EBECPT entry specifies 

byte area in jthe name cf the user's routine and/or if the WLBEEE 

which the IOCS | entry is included in the DTFBT definition, and 

places address |if I0ABEA2 is also included in this file definition, 
of wrong-length 1 

record or of | 

error block 1 

IGNORE I If the ERBOPT entry is omitted, a permanent read error 

^ causes the job to be terminated. When EBECET=naroe 

SKIP lis specified, the user must return to the IOCS via 

— ^register 14. 



name of user 
routine 



I 
-- 1- 



-H 



STC 
NSTD 



[Standard labels. 



NO 



name of the 

user-defined 

area 



I Non-standard labels. Applies to input files only 

|No labels. So labels is assumed if the FILABL entry 
lis omitted. 

I 
I 



name of the 
user- defined 
area 



IFirst DTF statement must be DTFEG EWC=YES. 



Figure 9. Definition Statement Summary for Tape Files, Part 1 of 2 
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Opera- 
tion 
t +- 



k- 



I Operand 



h- 



+— 



-+ + 

READ 



k 



Keyword 



lOBEG 



+- 



LABADDE 



RECFCBM 



i 

FIXUNB 



BECSIZE 



EEWIND 



TPMAEK 

+ 

TYPEFLE 



+ 

VABBLD 



WLEEBE 

ISOEKA 
_j 



Allowable 
Specification 



number of any 
register from 8 
to 13 in paren- 
theses (n) 



name of user 
routine 



FOBMABD 



BACK 



4 



Entry may be 
^unblocked. 



FIXBLK 



VAEDNB 




number of fcytes 
in one record 
or number of 
register indi- 
cating record 
length in num- 
ber of bytes, 
in parentheses 



UMLOAD 
NCEWD 



NO 



INFDT 



OUIPDI 



number of re- 
gister in 
parentheses (n) 
for available- 
byte indication 



Eemarks 



Beguired when 
in the I/C ar 
records are r 
area, or (3) 
processed in 
(If the user* 
instructions 
Character Bea 



either (1) blocked records are proces 
ea, or (2) variable length unblocked 
ead backward and processed in the inpu 
records (either blocked or unblocked) 
the I/C area and ICABEa2 is specified, 
s problem prograa contains ICCS macro 
that refer to the lEE 1259 or ^H^S Hag 
ders, registers 11 and 12 must not be 



sed I 

I 

t I 

are I 



User must ret 
macro instruc 



urn to main program by issuing a LEBET 
ticn. 



If omitted, ICC£ assumes forward reading. 



I 

I 

n€t4c| 

used) I 

-H 

I 

I 



omitted if record format is fixed 



Beguired if fixed-length blocked or undefined record 
format is specified. 

(If the user's problem program contains ICCS macro 
instructions that refer to the lEK 1259 or ^^^9 Magne 
Character Beaders, registers 11 and 12 must not be us 



tici 
ed) I 



If omitted, the tape 
on OPEH, CLOSE and on 



is rewound, but not unloaded 
end-of-volume condition. 



Applies tc unlabeled tape output files. 



Beguired if variable- 
are built in the cutp 
problem program conta 
that refer to the IBM 
Beaders, registers 11 






length blocked records 
ut area. (If the user's 
ins ICCS macro instructions 
1259 or 1*419 Magnetic Character 
and 12 must not be used.) 



name of user 
routine 

|YES 1 



The user must return to the ICCS via register 14. 



— ^ 



Figure 9. Definition Statement Summary for Tape riles. Part 2 of 2 
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INITIALIZATIOM 



OPEN second file 



Before the first record can be read from 
any input file or transferred to any output 
file by oeans of IOCS macro instructions, 
that file must be readied for use by issu- 
ing an OiPEN macro instruction. 



CtCSE second file 



OPEN fourth file 



OPEN BACBO INSTBDCTION 

The format of this macro instruction is: 



CLOSE fourth file 



CEEN sixth file 



I Name | Operation | Operand 

I 1 1 

|[name]| OPEN 

L J. 



I 

I filel ,file2, . . .f ilen | 



Each operand is the name of a file 
(assigned to it by an entry in the name 
field of a DTFSE (DTFMT) header entry) to 
be opened with this macro instruction. Any 
number of files from one to sixteen may be 
opened with one OPEN macro instruction. 
The operations performed depend on the type 
of unit involved and the labeling technique 
(if applicable) . 

0£enin5_Card_Files 

For card and printer files, an OPEN macro 
instruction simply makes the file (s) con- 
cerned available for input and/cr output. 

Opening Tape Files 

When a tape file with IBH standard labels 
is opened, the IOCS expects the first rec- 
ord read to be a label. An OPEN macro 
instruction causes the tape to be rewound 
prior to processing, unless the programmer 
has specified no rewinding by including 
EEWINB= NOEWE in the DTFMT Statement for 
the file. If the programmer has specified 
no rewinding and if a file beginning in the 
middle of the reel is opened, the user can 
position the tape by means of a FILES con- 
trol statement for the Job Control program 
so that the first record read at OPEN time 
will be a label. If the first record is 
not a label the IOCS regards it as an error 
condition. However, an unlabeled file can 
be opened in the middle without causing an 
error condition. 

When two or more files of a multifile 
tape volume are to be processed by one pro- 
blem program, processing of each specified 
file must be completed before the file next 
in succession is opened. 

Examjjlej. If the second, fourth, and sixth 
files of a multi-file tape volume are to be 
processed by one problem program, the pro- 
grammer must write the OPEN macro instruc- 
tions for these files in the following 
sequence: 



CLOSE sixth file 



Ihe concurrent processing of two or more 
files of a multifile tape volume is not 
possible. 

Note that all files on a multifile 
vclume must either contain the same type of 
labels (standard or non-standard) or con- 
tain no labels. 

OPENING TAPE INIOT FILES: The processing 
done by the IOCS when an OPEN macro 
instruction is executed depends on whether 
the file has IBM standard labels, non- 
standard labels, or no labels. If the 
input file is to be read backward, the file 
must meet the requirements specified under 
Bead-Eackward Considerations below. An 
OPEN macro instruction causes the 
following : 

1 . If lEK standard_labels are specified, 
the I0CS~wIll7~ 

a. read and check the volume label if 
the tape is at load point; 

b. bypass any user volume labels; 

c. read and check the lEK standard 
file header label (HDE1) ; 

d. bypass any additional IBM standard 
header labels (aEE2-EEB8) ; 

e. test the user labels (UHL1-UHL8) , 
if a user's routine is specified, 
and make these labels available to 
the user's routine as they are read 
(refer to the Note below) ; and 

f. properly position the tape to read 
the first data record. 

Jote : If a user's label routine is net 
specified, user labels (if present) are 
skipped. 

If the file is to be read backward, 
steps e, d, and c are performed in this 
sequence; steps a and b are omitted 
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because the ICCS processes trailer 
labels instead of header labels. 



2. If non-standard_labels are specified, 
the file is spaced forward to the first 
record following the first tape mark. 
Therefore, the non-standard labels must 
be followed by a tape mark. 

3. If nq,_ labels are specified, the first 
record on tape may be a data record or 
a tape mark followed by one or more 
tape marks. If the record is not a 
tape mark, it is assumed to be a data 
record, and the tape is backspaced by 
one record. If the first record is a 
tape mark, another record is read. If 
this record is a tape mark, the IOCS 
causes no further tape movement; other- 
wise, the ICCS assumes a data record 
and causes the tape to be backspaced by 
one record. 

2ead-Backward_£onside rations,^ 9- track tape 
files written on System/360 tape units can 
be read backward if they do not contain 
variable-length blocked records; 7-track 
tapes can be read backward if they were 
written on System/360 tape units without 
using the Data Conversion feature. Note 
that 7-track tapes containing variable- 
length records have always been written 
using the Data Conversion feature and, 
therefore, can not be read backward. A 
file to be read backward is limited to one 
reel. Any tape mark sensed while reading 
data records is considered to indicate an 
end-of-file condition. 

When opening a tape file that is to be 
read backward, the job is terminated if the 
first record read is not a tape mark. The 
user is required to properly position files 
that are to be read backward prior to issu- 
ing an OPEN macro instruction. The proper 
positions are as follows: 

IBM gtandard^labeled files should be posi- 
tioned so that the first record read will 
be the tape mark following the trailer 
label set. Since the file trailer label is 
the first label to be checked when a file 
is to be read backward, this trailer label 
must be complete; it must contain both the 
trailer and the header information {except 
HDE) to properly identify the file. If the 
file labels were originally written by the 
IOCS, the trailer labels are complete. 

^on-standard_latel_files should also te 
positioned so that the tape mark following 
the trailer label set is the first record 
to be read. However, no label checking is 
performed. 

Unl abel ed files must be positioned so that 
the first record read is the tape mark fol- 



lowing the last record of the file to be 
read. 

Unlabeled tape files to be read backward 
must have a tape mark as the first record 
en the tape (preceding the first data rec- 
ord) . If this tape mark is not present, no 
end-of-file (EOF) condition is detected and 
an attempt is made to read past the load 
point . 

The user must specify the NCEWE (no re- 
wind) option in his file definition state- 
ment for the file to be read backward. 

OPENING TAPE CDTPDT FILES: The processing 
done by the IOCS when an OPEN macro 
instruction is executed depends on whether 
or not the file is labeled. An OPEN macro 
instruction causes the following: 

1. If lEK standard labels are specified, 
the IOCS will: 

a. check for a volume label if the 
file is positioned at loadpoint; 

b. read the file header label (if pre- 
sent) and check the expiration date 
to make sure the data on the tape 
is no longer active and may te 
destroyed; 

c. backspace the tape and write the 
new file header label with the 
information supplied by means of a 
TPLAE job control statement (refer 
to the section Control Statements) ; 
and 

d. enter the user label routine, if 
this routine is specified, to allcw 
the creation and writing of user 
header label (s) (UKI1-UHL8) . 

2. If no_labels are specified, the ICCS 
will perform the rewind operation and 
write a tape mark as the first record 
on the tape. The volume label and the 
expiration date are not checked, and 
any existing lahel set is destroyed. 

Note^ The writing of a tape mark may 
be suppressed by a TPliiARK = NC entry in 
the DTFMT statement. 

3. If non2Standard_ljtels are specified 
for a file, a diagnostic message is 
printed during assembly because the 
specification of non-standard latels 
for an output file is not permitted. 



P|CCE^SING_KACEO_INSTEUCTICKS 

These macro instructions cause input/output 
operations to be performed. If an operand 
of a processing macro instruction is the 
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syabolic address of an area or a rootine, 
relative addressing is peraitted. However, 
such an operand is linited in length to 
eight characters, including expressions 
with their operators. 

The processing nacro instructions common 
to all input/output devices are described 
first followed by a separate section each 
on (1) specific card and printer macro 
instructions and (2) specific tape macro 
instructions. 

COHMON MACRO INSTRUCTIONS 

In this section, processing macro instruc- 
tions common to all input/output devices 
(GET, PDT, and CNTRL) are discussed. 

GET MACBO INSTRUCTION 

The format of this macro instruction is: 



IName 1 Operation | Operand 
j 1 1 



|[ name]|GET 

L I 



filename[ , workname ] j 



The GET macro instruction is written in 
one of two forms: 

1. With one operand only. This format 

applies to tape files only. It is used 
if records are to be processed directly 
in the input area. The operand speci- 
fies the name of the file from which 
the record is to be read. The file 
name must be the same as the one speci- 
fied in the DTFMT header entry for this 
file. 



areas are specified, the IOCS routines 
transfer records alternately to each area. 
They handle this "flip-flop" so that the 
next consecutive record is always available 
to the program for processing. 

Khen records are processed in the input 
area(£), a general purpose register must be 
specified in the DTFMT entry lOEEG, if: 

1. records are blocked, 

2. variable-length unblocked tape records 
are read backward, or 

3. two input areas are used, for either 
blocked or unblocked records. 

This register always contains the abso- 
lute address of the leftmost position of 
the record currently available. The GET 
routine places this address in the 
register . 



Iloce£sina_in_a_Hor k_Ar ea : The second form 
of the GET macro instruction is used if 
records are to be processed in a work area. 
It causes the GET macro to move each indi- 
vidual record from the input area to a work 
area. In the case of variable- length rec- 
ords the record includes four bytes which 
hold the record length. As in the first 
form, the file name must be entered as the 
first operand. The name of the work area 
must be entered as the second operand, and 
YES must be specified in the HOBKA entry of 
the DTFKT oi ETISB statement. The work- 
area name must be the same as that speci- 
fied in the ES or EC instruction defining 
this area. 



2. With two operands. This format is used 
if records are to be processed in a 
work area. The first operand specifies 
the name of the file. The second 
operand specifies the work area to be 
used. (Refer to the description of the 
WORKA=YES detail entry in the sections 
PTfSB Detail Entries and DTIMI_petail 
Entries . ) 

l£o c€jssing_in_a n_ Inpu t_ Ar e a : The first 
form of the GET macro instruction is used 
if records are to be processed directly in 
the input area (s) . It requires only one 
operand. This operand specifies the name 
of the file from which the record is to be 
retrieved. The file name must be the sane 
as that specified in the DTFMT header entry 
for the file. 

The input area must be specified in the 
DTFMT entry I0ABEA1. Two input areas may 
be used to permit an overlap of data- 
transfer and processing operations. The 
name of the second area is specified in the 
DTFMT entry I0AREA2. Whenever two input 



All records from a fil 
in the same work area, or 
from the same file may be 
ferent work areas. In th 
GET macro instruction for 
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moved into the work area along with the 
record. 



When a card file is processed in the 
non-overlap mode, a GET macro instruction 
for the file (1) initiates the reading of 
the next record, (2) moves the data from 
the input area to the work area when the 
read operation is complete, and (3) trans- 
fers control to the main program. When a 
card file is processed in the overlap mode, 
the GET macro instruction for the file (1) 
moves a record, as soon as it is available, 
from the input area into the work area, (2) 
initiates the next read operation, and (3) 
immediately transfers control to the main 
program. 

When a combined file is processed and 
data is to be punched into the input cards, 
the programmer must use one of the program- 
ming methods described under jPrccjraimin^ 
with_LOM_and EOM Macro Instructions in the 
section LCM Macro Instruction_for_Combined 
Fi le s. Also refer to Proararamina_Consid- 
erations_--_Combined_Files in the section 
FDT Macro Instruction below. 



For a tape input file, a GET macro 
instruction may cause a read forward or a 
read backward operation. The type of read 
operation performed is determined by the 
READ= entry in the DTFMT statement. 



PUT MACEO INSTRUCTIOH 

The format of this macro instruction is: 



j Name | Operation | Operand 

|[name]|PUT |filename[ ,workname ] | 

This macro instruction is written in one 
of two forms: 

1. With one operand only. This format 
applies to tape files only. It is used 
if records are to be processed directly 
in the input/output area. The operand 
specifies the name of the file for 
which the user wishes the PUT to be 
executed. The file name must be the 
same as the one specified in the DTFKI 
header entry for the file. 

2. With two operands. This format is used 
if records are being processed in a 
work area. The first operand specifies 
the name of the file. The second 
operand specifies the work area from 
which the records are moved to the out- 
put area. 



B ui^d i n£[_ i n_an_0 u t£ u t_ A r € a : The first form 
of the POT macro instruction is used if 
records are to be built directly in the 
output area(s}. It reguires only one 
operand. This operand specifies the name 
of the file to which the record is to be 
transferred. The file name must be the 
same as that specified in the DTFMT header 
entry for the file. 
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Khen records are built in the output 
area (s) , a general purpose register must be 
specified in the DTFMT entry ICBEG, if: 

1. records are blocked, or 

2. two output areas are used, for either 
blocked or unblocked records. 

This register always contains the abso- 
lute begin address for building the next 
record in the output area. 

Build inc|_in_a_Work_ Area: The second form 
of the PUT macro instruction is used if 
records are to be built in a work area. 
Ihis form of the PUT macro instruction 
moves a record from a specified work area 
to the proper location in the output area 
specified in the DTFMT or DTFSR statement. 
As in the first form, the file name must be 
entered as the first operand. The name of 
the work area is entered as the second 
operand. YES must be specified in the 
WOEKA entry. The name of the work area 
must be the same as that specified in the 
DS or DC instruction that defines the area 
in main storage. Individual records for a 
logical file may be built in the same work 
area or in different work areas. Each PUI 
macro instruction specifies the work area 
where the completed record was built. 
However, only one work area can be speci- 
fied in any one PUT macro instruction. 



Unblocked_Records 

Records transferred to card or printer out- 
put files are always considered to be 
unblocked. Records transferred to magnetic 
tape output files may be blocked or 
unblocked. If they are to be treated as 
unblocked this must be specified in the 
DTFMT entry RECFORM. 
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Each PUT transfers a single unblocked 
(either fixed or variable-length) record 
from the output area (or input area if 
updating is specified) to the file. If a 
work area is specified in the PUT macro 
instruction, the record is first moved froa 
the work area to the output area (or input 
area) and then to the file. 

Blocked_gecords 

When blocked records are to be written on 
tape (as specified in the DIFBT entry 
RECFOEM) , the individually built records 
must be formed into a block in the output 
area. The block of records is then trans- 
ferred to the output file. The blocked 
records may be either fixed or variable 
length. 
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The user's program must determine whether 
each record to be built will fit in the 
remaining portion of the output area. This 
must be known before processing of the rec- 
ord is started, so that, if the record will 
net fit, the completed block can te written 
and the record can be built at the begin- 
ning of a new block. Thus, the length of 
the record must be pre-calculated and com- 
pared with the amount of remaining space. 
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Undefined Records 
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Variable-len5th_blocked_records can also 
be built in either the output area or in a 
work area. The length of each variable- 
length record must be determined by the 
problem program and included in the output 
record as it is built. The record-length 
field must occupy the first four bytes of 
each record. The first two bytes specify 
the length of the record (including the 
four bytes for the record-length field 
itself) , and the next two bytes are binary 
zeros. The user must define an output area 
that is large enough to accommodate the 
four bytes in which the IOCS places the 
block-length indication. The block-length 
includes the four bytes for the block- 
length field itself. 
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If variable-length blocked records are 
to be built directly in the output area, an 
additional ETFMT entry, a TEUNC macro, and 
additional user programming are reguired. 



When undefined records are handled, PUT 
treats them as unblocked. The programmer 
must provide any blocking he wants. He 
must also determine the length of each rec- 
ord (in bjtes) and load it in a register 
for IOCS use, before he issues the POT 
macro instruction for that record. The 
register that will be used for this purpose 
must be specified in the ETFHT entry 
EECSIZE. 

When a card file is processed in the 
ncn-cverlap mode, a POT macro instruction 
for the file (1) moves a record from the 
work area to the output area, (2) initiates 
the punch operation (and the next read 
operation in case of a combined file) , and 
(3) transfers control to the main program 
when the punch operation has been 
completed. 

When a card (or printer) file is pro- 
cessed in the overlap mode, a POT macro 
instruction for the file (1) moves a record 
from the work area to the output area, (2) 
initiates the punch (print) operation, and 
(3) immediately transfers control to the 
main program. 

Note: Printer files are always processec' 
in the overlap mode. 

neither the output area nor the work 
area (if used) is cleared by the ICCS when 
a PUT macro instruction is executed. To 
avoid his output records containing inter- 
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spersed characters from preceding records, 
the user must ensure the following: 

1. If the records are built in the output 
area 

a. that the record he builds uses 
every position of the output area, 
or 

b. that he clears the output area 
before he starts building his next 
record. 

2. If the records are built in a work area 

a. that the record he builds uses 
every position of the work area, or 

b. that he clears the work area before 
he starts building his next record. 

j£OiliafflJ5ina_ConsiJerations_--_Combin€d 
Files 

Assume that a combined file is being pro- 
cessed by means of the following sequence 
of instructions: 

GET F1,W1 

no GET, EOH, or PUT 

macro instruction 

referring to file F1 

PUT F1,W2 

In this case, the following rules apply: 

Non-over lap . Mode . The statement PUT F1,W2 
causes punching into the card that has been 
made available by the statement GET F1,W2. 
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CNTBL MflCEO IHSTBUCTION 

The format of this instruction (control) 
is: 
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The CNTBL macro instruction can be used 
by the programmer to cause such non-data 
transfer operations as form skipping, 
stacker selection, tape rewinding, etc., to 
be performed on the device associated with 
the file, h CC»TBCL=IES entry must be 
included in the DTFSR (DTFMT) statement for 
a particular file if a CKTBL macro instruc- 
tion is given for the file. 

The following is a description of avail- 
able mnemonics to be used as the second 
operand, and of the contents of the third 
and fourth operands, when required. 

S Tfl C K E B_ S J L J CT I C K_ J SSi_l C B_ T H J_ IE H_ 25 2 0^ 
M0DELS_A1^_A2^_AND_A3: Either of two 
stackers can be selected. 



I Cperand | 

I : , -r \ 

I Mnemonic ] n I m | 



Function 



1 

I S£ I 1 I - I Select stacker 1 | 
I S£ 1 2 I - I Select stacker 2 1 



In the lEK 2520, cards are normally 
stacked in stacker 1. The stacker selec- 
tion mnemonic (SS) is used to select a card 
into the other stacker as specified by the 
third operand in this macro instruction. 
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1' P£o c ess i n ci_ i n_ overla£_ mo de^ The stack- 
er select CNTBL must be the last macro 
instruction preceding the GET or PUT 
that refers to the card to be selected. 
The example below selects the card, the 
contents of which are transferred to or 
from the work area by the GET (or PUT) 
macro instruction. (The second operand 
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required in GET (PUT) oacro instruc- 
tions referring to card or printer 
files is not shown.) 

CHTEL AAS,SS,n 

no GET or PUT 

referring to file AAA 

GET (PUT) AAA 

2« Processing7in-non -over lap mode. The 
stacker select CNTRL must be issued 
after the GET macro instruction or 
before the PUT macro instruction that 
moves the card to be selected. The 
example below selects the card read by 
the GET macro instruction. 

GET AAA 

no POT, GET or ECM 

referring to file AAA 

CNTRL AAA,SS,n 

The example below selects the card 
moved by the PUT macro instruction. 

CSTRL AAA,SS,n 

no PUT, GET, or EOM 

referring to file AAA 

PUT AAA 

STACKER_SELECTION_iSSl_FOR_THE_IBM_256 
MFC M; Any one of the five available stack- 
ers can be selected. 



IBB 2560 HFCH, does not specify a file 
name. Absence of the file-name operand is 
indicated by a comma. 



When two CNTRL macro instructions 
without a file name are given before the 
stacker select operation is performed, the 
second stacker selection is effective; 
i.e., the second CNTRL macro instruction 
overrides the first. 



Execution of this type of a stacker 
select CNTRL requires that the card to be 
selected is in the pre-print station when 
the subsequent PUT, GET, or EOH macro 
instruction is executed. 

lo ensure the instruction is in proper 
relationship to the GET, PUT, or ECM macro 
instruction referring to the card to be 
selected, the programmer must observe the 
following : 

1 • processing ^in_ overlap. mode. 

If the card to be selected is punched 
by a PUT macro instruction or if the 
contents of the card are moved to a 
work area by a GET macro instruction, 
then the CNTRL macro instruction must 
be given prior to any subsequent PUT, 
GET, or EOM macro instruction addres- 
sing an KFCM file. This is illustrated 
by the coding example below. (The 
second operand required in GET (PUT) 
macro instructions referring to card or 
printer files is not shown.) 



1 Mnemonic 



Operand | 

n I m I 
}_ ^. 



Function 



I 

I S£ 

1 SS 

I 



I SS 

J. — ^ — 

I SS 

j SS 

I 



1 I - I Select stacker 1 | 
— + ^ ^ 

2 1-1 Select stacker 2 1 
i. _| , 

3 1 - I Select stacker 3 1 
^ 1 1 



4 1 - I Select stacker 4 | 
+ + ^ 

5 1-1 Select stacker 5 1 



The CNTRL macro instruction for the IBM 
2560 MFCM may have one of two formats: 

1. CNTRL Filename, S£,n 

2, CNTRL ,££,n 

If the first format is used, the func- 
tions are the same as described for the 
stacker select CNTRL macro instructions for 
the IBM 2520, Models A1, A2, and A3- 

The second format, which is only possi- 
ble for card files to be processed by an 



PUT (or GET) F1 

Ho POT, GET, or 

ECK referring to 

MFCM files 

CNTRL ,S£,n 

2 • Processing in non-overlap mode. 

If the card to be selected is punched 
by a PUT macro instruction, the CNTRL 
macro instruction must be given prior 
to any subsequent GET, PUT, or EOM 
macro instruction addressing an MFCM 
file (see the coding example below) . 

PUT F1 

No PUT, GET or 

ICK referring to 

I5FCM files 

CNTRL ,SS,n 

There is one exception to the above. 
Between the PUT for a card to be 
selected and the CNTRL for this card, a 
GET for the same file may be inserted 
(see the coding example below) . 
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POT F1 

No PDT, GET, or 

EOM referring to 

PIFCM files 

GET F1 

Ho POT, GET, or 

£0M referring to 

jjFCM files 

CNTRL ,SS,n 

When the card to fce selected is read by 
a GET macro instruction, another GET, 
EOM, or PUT to the same file must be 
given prior to the CNTRL macro instruc- 
tion for this card (see the coding 
example below) . 



GET F1 

any combination of 

macro instructions 

referring to another 

__ file. 

GET F1 (or PUT F1) 
(or EOM F1) 

No PUT, GET, or 

EOM referring to 

MFCM files 

CNTBL ,SS,n 



I01M_SPiCING_JSPL_I0R_PEINTEES: Line spac- 
ing on printers can be controlled. 



1- 

Mnemonic | n | m 

SP 1 n I I Space n 

(n = 0,1,2, or 3) 
lines immediately 



Operand 



SP 



SP 



Function 



Space n 

(n = 0,1,2, or 3) 
lines immediately 
and m 

(m = 0,1,2, or 3) 
lines after printing 



Space m 

(m = 0, 1, 2„ or 3) 
lines after printing 



This mnemonic is required to control 
line spacing. The programmer may omit 
either operand n or m. If operand n is 
omitted, the omission must be indicated by 
a comma (Example: CNTRL Filename, SP,,2). 

If a delayed spacing CNTRL macro 
instruction is not given before the next 
PUT for the same file, the form is automat- 
ically spaced one line after printing. 



When two delayed spacing CMTEL macro 
instructions are given before the next POT 
for the same file, the second CNTBL is 
effective, i.e., the second CNTRL overrides 
the first. If both delayed spacing and 
skipping are specified before a PUT for the 
file, only the last specified operation 
will be performed. 



Both the delayed-spacing an 
immediate-spacing specificatio 
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In order to increase system throughput, 
delayed spacing should be used whenever 
possible. 

FORM SKIPPING (£K) FOR PRINTERS; Skipping 
to a specific line on a printed form can be 
controlled. 



1 — 



SK 



Operand 
Mnemonic 



SK 



SK 



-r -I 

n I m 
j — 

n 



+ V 



Function 



Skip to punch in 
channel n (n=1 , 2, . 
12) immediately 

Skip to punch in 
channel n (n=1 ,2, . 
12) immediately a 
to channel 
m (m=1,2, . . . , 12) 
after printing 



• • # 

nd 



— ^ 



Skip to punch in 
channel m(m=1,2,., 
12) after printinc 



The form-skipping mnemonic is used to 
specify the channel of the carriage control 
tape to which the form is to be skipped 
immediately and/or after the printing of a 
line. The programmer may omit either 
operand n or ra. If operand n is omitted, 
the omission must be indicated by a comma. 
Example: CNTBL filename, SK, , 12. 

When two delayed skipping CNTBL macro 
instructions are given before the next PUT 
fcr the printer file, the skipping speci- 
fied in the second CNTRL macro instruction 
is effective, i.e., the second CNTBL over- 
rides the first. 
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In order to increase system throughput, 
delayed skipping should be used whenever 
possible. 



IAPE._D NI T_C OHTBOL : For a tape file, a 
CNTBL macro instruction may be issued any- 
where in the problem program. 

The CHTEL macro instruction is used to 
control magnetic-tape functions that are 
not concerned with reading or writing data 
on the tape. The file name and the mnemon- 
ic specifying the desired operation are the 
only operands required in CNTRL macro 
instructions for tape files. Each mnemonic 
used is described separately below. 

The FSH (or BSB) function permits the 
user to skip over a physical record (from 
one interrecord gap to the next). The rec- 
ord skipped is not read into main storage. 
The FSF (or BSF) operation permits the user 
to skip to the end of the logical file, 
which is identified by a tape mark. 



y . 4 



Mnemonic 1 Function | 

BSF I Backspace tape to 

Ipreceding tape mark. 

BSR I Backspace tape for one 
I block. 

-+- 
EBG 1 Erase tape to produce 
I a gap. 

FSF I Forward-space tape to 
I next tape mark. 

FSE 1 Forward-space tape to 
I next inter-block gap. 

REW iRewind tape. 
1 

RON IRewind and unload tape. 
I- + 

1 WTM I Write a tape mark. 

I u 



When a CNTRL macro instruction with BSB 
or FSR as the second operand is issued for 
a tape input file, the programmer must con- 
sider the relative position of the tape to 
the record being processed. 

For all I/O area combinations, with the 
exception of one I/O area and no work area, 
IOCS reads the physical tape record follow- 
ing the one that is being processed at the 
time. Therefore, if a CNTRL FSE function 
is performed it is the second physical tape 
record following the one being processed, 
which will be skipped over. 

One_lZO_Area_and_No_Work_Area. A CNTRL 
with BSR as the second operand causes: 



1 . For a file that is read forward — the 
tape to be positioned so that the rec- 
ord being processed is in proper posi- 
tion to be read on the next read- 
forward operation. 

2. For a file that is read backward — the 
tape to be positioned so that the 
second record after the one being pro- 
cessed is in proper position to be read 
on the next read-backward operation. 

A CNTRL with FSR as the second operation 
causes : 

1 . For a file that is read forward — the 
tape to be positioned so that the 
second record after the one teing pro- 
cessed is in proper position to be read 
on the next read-forward operation. 

2. For a file that is read backward — the 
tape to be positioned so that the rec- 
ord being processed is in proper posi- 
tion to be read on the next read- 
backward operation. 

All_I/0. Combinatigns.,_ with_the exception., of 
One I/O Area and Mo Work Area. A CNTRL 
with BSR as the second operand causes: 

1 . For a file that is read forward — the 
tape to be positioned so that the block 
after the one whose last record is 
being processed is read on the next 
read-forward operation. 

2. For a file that is read backward — the 
tape to be positioned so that the third 
block after the one whose last record 
is being processed is read on the next 
read-backward operation. 

A CNTBL with fSR as the second operand 
causes : 

1. For a file that is read forward — the 
tape to be positioned so that the third 
block after the one whose last record 
is being processed is read on the next 
read-forward operation. 

2. For a file that is read backward — the 
tape to be positioned so that the block 
after the one whose last record is 
being processed is read on the next 
read-backward operation. 

Before forward or backward-spacing 
operations (FSR, FSF, BSB, or ESF) , the 
magnetic tape is positioned at an inter- 
block gap. 

If blocked input records are being pro- 
cessed, and if the user does not want to 
process the remaining logical records in 
the block or one or more succeeding blocks, 
he must issue a RELSE macro instruction 
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before the control macro instruction. The 
next GET will then make the first record of 
the new block available for processing. 
If/ for example, the CNTHL macro instruc- 
tion with FSB is issued without a preceding 
RELSE, the tape is advanced, but the next 
GET will make the next record of the old 
block available for processing. 

When a CNTBL macro instruction is issued 
for a tape output file, the programmer 
should issue a TRUNC macro instruction 
(TRUNC = truncate) if it is desired that a 
partially filled Jalock of records be writ- 
ten on tape before the CNTRL macro instruc- 
tion for the file is executed. 

If an FSR function (or BSR for a file 
that is being read backward) encounters a 
tape mark, the IOCS branches to the user's 
end-of-file routine. 

The functions of the individual mnemonic 
are described below following the section 
Eff ect of _CjjTRL_gn„ Block, Count . 

Effect of CNTRL on Block Count. Hhen a 
CNTRL macro instruction with BSF, BSR, FSF, 
or FSR as the second operand is issued, the 
block count written or checked for standard 
labels may be wrong. The control routine 
does not update the block count. If a tape 
input file with standard labels is speci- 
fied and the block count is in error at end 
of volume or end of file, a programmed halt 
occurs. 
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F£g {Forward„Space to Inter-Elock Gap) . 

This mnemonic is used if one block is to be 
skipped. The IOCS tranches immediately to 
the user's end-of-file routine if (1) an 
FSB operation is performed for an input 
file and (2) a tape mark is detected as a 
result of this FSB operation. When an FSR 
operation is executed, the IOCS causes the 
tape to be stopped with the block following 
the one just skipped in proper position to 
be read on the next read forward operation. 
Refer to Effect of CSTBI on Eij-ock Count. 

Note: ESE or ESF always move the tape 
towards load point, regardless of read for- 
ward or read backward mode. 
FSB or FSF always move the tape away frco 
load point, regardless of read forward or 
read backward mode. 

BlW__[Rewind_Ta£eljL This mnemonic is used 
if a tape rewind operation is desired. 
When a REW operation is executed, the IOCS 
causes the tape to be stopped with the 
first record on the tape in proper position 
to be read on a read forward operation. 
The record may be (1) a volume label if 
standard labels have been specified, {2) a 
tape mark or a data record if no labels 
have been specified, or (3) a non-standard 
label if non-standard labels have been 
specified. 

RU£ {Rewind, and.. Unload. Tape) . This mnemon- 
ic is used if the programmer desires a tape 
rewind operation to be followed by a tape 
unload operation. 

HTH IJrite_Ia£e_Karkljt This mnemonic is 

used if a tape mark is to be written. 



SPECIFIC CARD AND PRINTER MACRO 
INSIBDCTICNS 

KacEO instructions pertaining to card and 
printer files {CRDPR, EOM, LOM, and WAITC) 
are discussed in this section. 



ERG {Erase_Gap)^_. This mnemonic is used to 
erase all signals that may be recorded on a 
section of tape; i.e., it creates a length 
of blank tape (approximately 3 1/2 inches) . 



CRDPB KACEC INSTEUCTICN 

This macro instruction is only applicable 
if the user has an IBM 2560 MFCM equipped 
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«ith the card print feature. The format of 
this lacro instruction (CaRD PBint) is: 



J , J. 

I Name jOperation | Operand 
1 1 1 



-H 



|[name]|CEDPB 
I X. 



I ,wcrknarae, cardprintarea I 



, Because this instruction does not refer 
to a specific file, it does not have a 
file-name operand. The absence of this 
operand is indicated by a comma. The 
second operand is the name of the work 
area, and the third operand is the name of 
the card print area. 

A CBBPB macro instruction moves one line 
of information from the specified work area 
to the card print area. However, printing 
does not take place until the card is being 
moved into and through the print station by 
the execution of a subsequent GET, PUT, or 
EOM macro instruction. It is therefore of 
particular importance that the programmer 
writes his CBEPB statement in proper rela- 
tionship to PUT, GET, or EOH macro instruc- 
tions related to the same card. The same 
rules that apply to the stacker-select 
CHTEL macro instruction for the IBK 2560 
HFCM without a file-name operand are also 
applicable to the CBDPR macro instruction. 



CAUTION: When a CBDPR macro instruction is 
executed, the data that is contained in the 
specified work area is moved into the spe- 
cified card print area. If the programmer 
desires to have the contents of the cards 
of a file printed on the same cards and the 
file is processed in non-overlap mode, he 
must consider the following: Two GET macro 
instructions (or one GET and one PUT macro 
instruction are required to move a card to 
and through the print station. If the two 
work areas specified in the GET macro 
instructions are the same, the contents of 
the card that was read by the second GET is 
card-printed on the card that was read by 
the first GET. 

The programmer must write one CBDPR 
macro instruction for each line to be 
printed. If two CBDPR macro instructions 
are given for the same line, only the last 
of them will be executed. At the time of 
printing, all print lines specified for a 
particular card are printed simultaneously. 
It is not possible to print only with print 
head 1 during one print operation and then 
with print head 2 and/or another print head 
or with all print heads during another 
print operation. If no data is to be 
printed on a line, the programmer simply 
does not enter any data into the associated 
print area or, if processing was performed 
in the area, he clears the area before 



printing takes place. Befer to CEEPBLn=m 
in the section Additional petail Entries 
fo£_Card_Printin3. 



ECK RACEC IHSTEUCTICH 

The format of this macro instruction (Enter 
Overlap Mode) is: 



I Name | Operation | Operand 



|[name]IEOM 

I L 



I filename 



EOM is entered in the operation field 
and the name of the file to which the 
instruction refers is specified as the 
operand. 

An ECM macro instruction applies only to 
combined files for which a previous LCH 
macro instruction has been given (see 
below) . The EOM macro instruction causes 
(1) the next card to be read into the read 
area, and (2) subsequent GET macro instruc- 
tions referring to the same file to be 
executed in overlap mode. The processing 
of the file in overlap mode begins immedi- 
ately after the EOM macro instruction has 
been given, for further details regarding 
the use of the EOM macro instruction, refer 
to ICE_Kacio_ Instruction , below. 



LOM MACBO INSTBOCTION 

The format of this macro instruction (Leave 
Overlap Mode) is: 



IName lOperation |Operand | 

|[name]|LCK jfilename | 

I I ^ 1 1 



Except for the mnemonic in the operation 
field, the format of this macro instruction 
is the same as that of the ECM macro 
instruction. The LOM macro instruction 
applies to combined files for which overlap 
mode has been specified. The processing of 
the file in non-overlap mode begins when 
the next GET macro instruction for the spe- 
cified file is executed. This permits 
reading a card and punching into the same 
card of a combined file that is being pro- 
cessed in overlap mode. if an LCM macro 
instruction is given for a particular file, 
all subsequent GET instructions for that 
file are performed in non-overlap mode 
until an EOM macro instruction is given. 
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Programming Considerations - _ LO M_ a n d_ E M 
Macro Instructions 

a card of a combined file car, ce read and 
then punched only if the c?».id is read by a 
GET macro instruction in non-overlap mode. 
There are three possible ways to cause the 
GET to operate in non-overlap mode during 
this reading and punching of the same card: 

1. Provide an OVEBLAP=HO detail entry for 
the file. In this case, the IOCS 
generates GET and PUT routines for this 
file that operate in non-overlap mode. 

2. Do not provide an OVEELAP=NC detail for 
the file and, in the source program, 
give an LOM macro instruction between 
the OPEN and the first GET macro 
instruction for the file. In this 
case, GET and POT routines that operate 
in the overlap mode are generated for 
the file. However, all GET macro 
instructions for the file operate in 
non-overlap mode. 

3. Do not provide an OVEELAP=NC detail 
entry for the file and, in the source 
program, precede each GET macro 
instruction with an LOM macro instruc- 
tion and follow each GET with a test to 
determine if a punching operation is to 
be performed on this card. If not, 
operation of this file can be changed 
back to the overlap mode by an EOM 
macro instruction. 

The first method keeps storage require- 
ments at a minimum, but results in a 
decrease of program speed. 

The second method is the most satisfac- 
tory solution when nearly every card of a 
file must be both read and punched. The 
program speed does not decrease as much as 
with the first method because the PUT rou- 
tines will operate in the overlap mode. 

The third method is usually the most 
satisfactory solution when only a few spe- 
cified cards in a combined file must be 
both read and punched. When this method is 
used, each card is read in the non-overlap 
mode and thus can be punched subsequently. 
However, when punching is not to be per- 
formed, the program immediately begins 
operation in the overlap mode. This method 
(third) requires some additional main 
storage positions for the extra LCM and ECM 
macro instructions, but it results in a 
program that runs at nearly the same speed 
as a program operating entirely in the 
overlap mode. 

The coding below is an example of using 
the LOM and EOM macro instrcutions., This 
coding example assumes that (1) a combined 
file (AAA) is to be processed and {2) data 



is to be punched into each card of the file 
that contains a 7-punch in column 1. It is 
further assumed that an area named WCBKAAA 
has been defined. 

C0MPR1 LOM AAA 

CCKPE2 GET aii,WOEKa]ii 

CLI W0BKAAA,C'7' 

BE PUNCHE 

EOM AAA 



C0MPR1 



PCNCHE 



PUT 

B 



A£A,WOBR£AA 
C0MPB2 
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If punching is not required (no 7-punch 
in column 1) , the EOM macro instruction is 
executed, which causes the operating mode 
for the file to be changed back to overlap. 



PETOV KfiCEO ISSTEUCTION 

This macro instruction {PEinT Overflow) 
applies to printer files only. Its format 
is: 

I r r 1 

IBame |Cferation ICperand | 

1 ^ ^ ^ 

1 [name 3IPET0V I filename, n[ , address ] 1 

I : L L I 
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1 . the execution of the last PUT macro 

instruction referring to a printer with 
the standard carriage. 
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2. the execution of the last POT macro 
instruction referring to a printer with 
the dual feed carriage when only the 
lower feed is used, and 

3. the execution of the next to last PUT 
macro instruction referring to a print- 
er with the dual feed carriage when 
both feeds are used. 

However, if a skip has been performed 
after the last POT macro instruction (or 
after the next-to-last PUT if both feeds of 
a dual feed carriage printer are used) , a 
punch in channel 9 or 12 that may then be 
sensed is lost and cannot be determined by 
a PRTOV macro instruction. 
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whose cards are to be read in overlap 
mode. 

2. A programmed stop is required to permit 
an error card to be replaced in a file 
whose cards are to be read on the lEM 
2560 MFCM in non-overlap mode and a 
file in the other feed of the BFCH is 
to be processed in overlap mode. 

3. In case of a multi-phase program, the 
next program phase is to te loaded by 
means of a FETCH macro instruction. 

Except for the condition 2, above, a 
HAITC macro instruction need not be issued 
for the replacement of an error card if the 
cards of the file are to be read in non- 
overlap mode. 

lIoS£HJin3_iili]l_ihe_jJAITC_Macro 
Instruction 

A GET macro instruction that refers to a 
card file may or may not immediately initi- 
ate a read operation. This depends on the 
operating condition of the input/output 
device involved. If the initiation of the 
input/output operation is delayed, the IOCS 
places the device request into a waiting 
list. The IOCS handles the device requests 
in this waiting list and executes the 
appropriate input/output operation as the 
requested input/output devices become 
available. 



WAITC MACRO INSTRUCTION 

The format of this macro instruction ( WA IT 
Card) is: 



I Name J Operation [Operand 

1[ name] I WAITC | 

I I J 
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Since the WAITC macro instruction neith- 
er refers to a particular file nor requests 
a particular function, no operand is 
required. 
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In a program using the IOCS, a HAITC 
macro instruction must be issued if one of 
the following three conditions exists: 

1. A programmed stop is required to permit 
an error card to be replaced in a file 



The programmer has no means to determine 
the status of the waiting list at the time 
the error is detected. Moreover, he is not 
able to determine the exact position of the 
error card in the input/output device. 
Therefore, the standard restart procedures 
cannot be applied. 

Before he issues the HPB instruction, 
the programmer must issue a WAITC macro 
instruction to (1) establish uniform 
operating conditions for all card (and 
printer) input/output devices and (2) 
determine the exact position of the error 
card. 

After the execution of the WAITC macro 
instruction, the waiting list contains no 
pending input/output device requests, 
except those for card printing. The error 
card (to be fed as the first card on 
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restart) is determined by the number of 
cards that have to be returned to the input 
deck after the non-process runout. 

The number of cards to be returned to 
the input deck depends on the input/output 
device used and, in case of an HFCM file, 
on the mode of operation. For details, 
refer to Figure 10, which is a summary of 
the stop and restart information. 

DUHMY_GET_MACR0_INSTB2CTI0NS. To ensure 
proper program functions on restart, i.e., 
resume processing with the corrected card 
record, the programmer must issue either 
one or two dummy GET macro instructions as 
shown in Figure 10. For the explanations 
below, processing in the overlap mode is 
assumed, unless it is stated that the 
information applies to files that are pro- 
cessed in the non-overlap mode. 

After the execution of a WAITC macro 
instruction, the contents of the card fol- 
lowing the error card is already in the 
input/output area. Therefore, the first 
GET macro instruction that is encountered 
after restart causes the record from the 
card following the error card to be moved 
into the work area. To make sure that the 
contents of the corrected error card have 
been moved into the work area before normal 
processing is resumed, the first GET macro 
instruction encountered after restart must 
be a dummy GET, i.e., no processing must be 
performed on the record moved into the work 
area by means of this GET macro instruc- 
tion. If an IBM 2501 is used to read a 
card file and two input/output areas have 
been defined for this file, two dummy GET 
macro instructions are required. 

If an IBM 2560 KFCM is used to process 
two input and/or combined files in one pro- 



gram, an error card in one file requires 
one dummy GET macro instruction on restart 
for each of the files with one exception: 
only one dummy GET macro instruction is 
required for the file that contains the 
error card if (1) the other (non-error) 
file is an input file whose cards are read 
in non-overlap mode and (2) no GET has yet 
been given for the non-error file. The 
programmer must provide a switch to deter- 
mine whether or not a GIT has already teen 
executed for the non-error file. This is 
illustrated in the coding example shown in 
Figure 11. 



A GET macro instruction for a file that 
is to be processed in overlap mode may te 
preceded by a CNTRL macro instruction ref- 
erring to the same file. If this GET macro 
instruction detects an error card, the pro- 
grammer must do either of the following in 
his restart routine: 



1 . Bepeat the CNTBL macro instruction 
after the dummy GET macro instruction 
for the file in his restart routine. 

2. Branch to the CKTBL macro instruction 
preceding the GET macro instruction 
that detected the error card. 

Similar rules apply if two files are 
processed on the IBM 2560 MFCM in one pro- 
gram. Any file-dependent CMTEL macro 
instruction that precedes the last GET 
macro instruction in either file must te 
repeated after the dummy GET macro instruc- 
tion for the file and before resuming ncrm- 
al processing. A preceding file- 
independent CHTEI macro instruction (nc 
file name specified) need be repeated only 
once . 
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1" 

\ 
I 

Input/ I 
Output I 

Device | Mode of Operation 
k 4- 



2501 



I Non-overlap 

I Overlap with one input/ 
I output area 



I Overlap with two input/ 
I output areas 

2560 I 

Feed 1 |Hon-overlap 

I Overlap 

i 



2560 

Feed 2 JMon-overlap 
h 



2520 



I Overlap 

-+ 



j Non-overlap 



i Overlap 



HAITC 
required 



No 



Number of 
Duiamy GETs 

+ 





Yes 



les 



No* 



Yes ** 



1 



U 




lumber of Cards to be 
returned 

1 



Error Feed 



j. 



+-- 



-4 









Non-error 
Feed 



-i 



*WAITC macro instruction is required if a file in the other feed is processed in over- 
lap mode. 
**Only required for the file containing the error card. 2 dummy GET is required 
for both files. 



Figure 10. Programming with the HAITC Macro Instruction — Halt and Restart Information 
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An IOCS provided halt (due to a machine 
check) may occur during or immediately 
after the user-programmed restart routine 
and the number of cards in the input/output 
device may be less than stated in the 
appropriate standard procedure as provided 
in the SBL publication IBH_Sxstem/360_Mod€l 
2 Card Programming Support^ Input/Output 
Control System^^Operatinq Procedures , Form 
C26-3803. In this case, only those cards 
must be stacked manually which were in the 
card feed of the input/output device at the 
time the halt occurred and do not have to 
be returned into the respective hopper. 

The coding example in Figure 1 1 is pro- 
vided to illustrate programming with the 
WAITC macro instruction. The example 



includes a simplified restart routine. For 
the purpose of this coding example, the 
fcllowing is assumed: 



1. Two files (AAA and BBB) have been 
defined to be read in the two feeds of 
the IBM 2560 MFCM. 

2. File AAA is to be processed in the 
overlap mode and the cards of this file 
are to be fed form hopper 1 of the 2560 
MFCK. This file may be an input or a 
combined file. 

3. File BBB is an input file whose cards 
are to be read in non-overlap mode, 

4. Any card of file AAA that does not have 
a 1-punch in column 1 is an error card 
and must be replaced. 

Only those instructions that illustrate 
programming with the WAITC macro instruc- 
tion are shown in Figure 11. These 
instructions are identified by sequence 
numbers in parentheses in the rightmost 
column of Figure 11. These sequence num- 
bers are used as references in the explana- 
tions below. 



ae IBM System/360 Model 20 TPS IOCS 



1 Name 


Operation 
1 


Operand 




1 








• 
|GET 


EEB,W0RK2 






MVI 


SW+1,X'00» 






• 
CNTBL 


BBB,SS,U 




IRETPT 


• 
CNTRL 


AAA,SS,2 






GET 


AAA,W0RK1 






CLI 1 


W0RK1,C'1' 






BE 


NOEEH 






WAITC 








HPE 


X'FEF' ,C 






GET 1 


AAA,W0RK1 




isw 


B 


BYPASS 






GET 1 


BBB,W0RK2 






CNTEL 


BBB,SS,^ 




IBYPASSI 


B 1 


EETPT 




INOEGS 


1 

• 







Instr 
Sgnce 

+ ^ 



(1) 

(2) 



(3) 



d) 

(5) 

(6) 

(7) 

(8) 

(9) 

(10) 

(11) 

(12) 

(13) 

(Mi) 



Figure 11. Coding Example — Programming 
with the WAITC Macro 
Instruction 
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(7) is not pe 
executes the 
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two dummy GET 
dummy GET mac 

(10) is execu 
tion has yet 
EBB. In this 
named SW (11) 
dummy GET mac 

(12) and the 
instruction ( 
bypassed. Co 
blem program 
the CNTEL mac 
GET macro ins 
card to be de 



of file AAA does not contain a 
lumn 1, the branch to NOERB 
rformed and the program 
WAITC macro instrcution (8) 

an HPE instruction (9) . On 
program executes either one or 

macro instructions. Only one 
ro instruction for file AAA 
ted if no GET macro instruc- 
been executed for the file 

case, the branch instruction 

is executed and the second 
ro instruction for file BBB 
stacker select CNTEL macro 
13) for this file are 
ntrol is returned to the pro- 
by a branch to RETPT to repeat 
ro instruction preceding the 
truction that caused the error 
tec ted. 



If a GET macro instruction has already 
been executed for the file BBB at the time 
the error card is detected, the branch 
instruction named SW (11) is not executed. 
This instruction has been changed to a no- 
operation (EC 0) instruction by means of 
the MVI instruction (2) following the GET 
macro instruction (1) for the file BBB. 

The CNTRL macro instruction for file BBB 
(3) is only effective when no error card is 
detected. 



If an error card were detected, four 
cards would have to be returned for file 
AAA and two cards for file EBB. 



If the cards of the file EBE were to be 
read in overlap mode, instructions (2) and 
(11) would have to be omitted. 

If the cards of a combined file are also 
to be card-printed and this file is to be 
processed in non-overlap mode, the follow- 
ing must be considered by the programmer. 

Unless successive cards are to be read 
which are not to be punched, a GET macro 
instruction for a card does not initiate 
card movement. Card movement is initiated 
by the PUT macro instruction for the pre- 
ceding card. Therefore, the programmer 
must issue a dummy GET macro instruction 
prior to the WAITC macro instruction to 
ensure that the desired card-print opera- 
tion for the card preceding the error card 
is properly executed. This is further 
explained in the coding example shown in 
Figure 12. 



Same | Operation 






EEPT 



|GET 


|CMEF,WBKC 


ICLI 


1 WBKC,C' 1' 


IBE 


|8,NERR 


IGET 


|CKEF,WEKC 


1 WAITC 


1 


IHPB 


IX'FIF',0 


IB 


lEEPT 



KEBE i 



I. 
]. 

jPUT 

ICBEEE 

IB 



Operand 



Sgnce 



CMBF,WBKC 



REET 



Figure 12. Coding Example — Programming 
with the WAITC Kacro Instruc- 
tion Involving Card Printing 

The coding example in Figure 12 is based 
on the assumption that: 

1 . the first card of the file CKEF has 
already been read, 

2. data is to be punched into all input 
cards, and 

3. all cards without a 1-punch in column 1 
are error cards and must be replaced by 
the operator. 
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The sequence numbers shovn in the right- 
most column of Figure 12 are used as 
references in the explanations telow. 



If the car 
the normal GE 
the next EUT 
the preceding 
the card made 
is an error c 
the error car 
station and t 
card is prope 
the corrected 
of the normal 
the subseguen 
the time this 
executed for 



d that is made available by 
T (1) is not an error card, 
for the same file (8) causes 
card to be printed on. If 
available by the normal GET 
ard, the dummy GET (U) causes 
d to be moved past the punch 
he card preceding the error 
rly card-printed. On restart, 
error card is read by means 
GET (1) , punched by means of 
t PUT (8) , and card-printed at 

PUT macro instruction is 
the following card. 



The programming considerations that 
apply to card printing are also applicable 
to stacker-select CNTBL macro instructions 
without a file name as the first operand. 
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rupts that may have 
ng under control of 
m phase have been h 
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Note that a second or subsequent program 
phase cannot be loaded from a card input 
device in which data cards were read during 
any of the preceding program phases. 



SPECIFIC TAPE HACBC INSTBUCTICNS 

Macro instructions pertaining to tape files 
(LBBET, EELSE, and TBUNC) are discussed, in 
this section. 



LBBET MACBO INSTBUCTION 

The format of this macro instruction (LaBel 
BETurn) is; 



I 1 1 

I Name |Opera tion | Operand 

I 1 1 

|[name]lLEEET |1 
1[ name] I LBBET 12 
1 1 1 



The LBBET (label return) macro instruc- 
tion applies only to tape files that con- 
tain additional user labels, that the user 
wants to check or build/write. It must be 
issued at the end of the user's label rou- 



tine (specified by the ETIET entry 
LABAEDB) , to return to ICCS after header or 
trailer labels have been processed. This 
macro instruction requires one or both of 
the following operands: 



OPEBANB 1 

JjJiiioUJl_l3i§ls^_IIl£ui_Ji2e: To return 
to IOCS when the user wants to eliminate 
the checking of all remaining user labels, 
operand 1 is required. IOCS then skips the 
remaining labels in the set, and processing 
continues. If all labels are to be 
checked, operand 2 is used and ICCS ter- 
minates label processing when the tape mark 
following the last label is read. 

Additio|ial.^ labels^,, Cutput_ file : To return 
to IOCS when the user determines that the 
last additional user label has been built, 
operand 1 is used. ICCS writes the last 
label (from the label output area) and pro- 
cessing continues. Operand 1 is always 
required to terminate the output label set. 



OPEBANB 2 

A^Jliioj al- labels^-lnp u t_ f i le : Operand 2 
is required to return to ICCS after each 
additional user label has been checked. 
IOCS makes the next label, if any, avail- 
able for checking in the label input area. 
When IOCS senses the end of the label set 
(tape mark) , it terminates label 
processing . 

JJJiiioil§l_ljtelSj^_Out£Ut_f ile: Operand 2 
is required to return to IOCS after each 
additional user label e^ccept the last has 
been built. IOCS writes the label from the 
label output area and returns to the user's 
label routine to permit him to build his 
next label. The user must then use operand 
1 to terminate the output label set. 

The LBBET routine requires the values 
that the ICCS has placed into registers 1U 
and 15. Hence, if the user requires one or 
both of these registers in his routine, he 
must save the value placed into these reg- 
isters by the ICCS before he starts using 
them. He must restore this value prior to 
issuing the LBBET macro instruction. 



BELSE MACBO INSTRUCTION 

The format of this macro instruction 
(BELeaSE) is: 



IName lOperation lOperand 
I [ name ] I BELSE | filename 

I I X- 
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The name of the file to which this macro This 

instruction refers (name field entry on the junction 

DTFMT header entry line) is the only are to b 

operand required. prograani 

ords (bl 

This macro instruction is used in con- crds) . 

junction with blocked input records read issued, 

from tape. It allows the programmer to output r 

skip the remaining records in a block and block of 

continue processing with the first record written 

of the next block read when the next GET availabl 

macro instruction is issued. records-. 



macro instruct 
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idered full. The 
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e output area is made 
next block of 



The BELSE macro instruction can be used, 
for instance, in a job in which only the 
first three records of each block on tape 
are to be processed. In this case, three 
successive GET macro instructions followed 
by a RELSE macro instruction are required. 

Another example of using the BELSE macro 
instruction is a job in which records on 
tape are categorized,- and each category 
(perhaps a major grouping) starts with the 
first record of a block. Categories can be 
located readily by checking only the first 
record of each block. 

The BELSE macro instruction discontinues 
deblocking of the present block of records 
which may be of either fixed or variable 
length. BELSE causes the transfer of a new 
block to the input area. The next GET 
makes the first record available for pro- 
cessing, either by the initialization of a 
register or by moving the record to a spe- 
cified work area. 

a BELSE macro instruction causes no 
operation to be performed if the preceding 
GET: 

1. causes the last record of the block to 
be made available for processing in the 
input area; or 

2. causes the last record of the block to 
be made available for processing in a 
work area. 



The last record 
block is the recor 
the last EOT macro 
TBONC was executed 
are built in a wor 
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a new block, the T 
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Whenever variable-length blocked records 
are built directly in the output area, this 
TBUNC macro instruction must be used to 
write a completed block of records. When 
the PUT macro instruction is issued after 
each variable-length record is built, the 
output routines supply the programmer with 
the space (number of bytes) remaining in 
the output area. From this, the programmer 
determines if his next variable-length rec- 
ord will fit in the block. If it will not 
fit, he issues the TBUKC macro instruction 
to write out the block and make the entire 
output area available to build the record. 
The amount of remaining space is supplied 
in the register specified in the ETEHT 
vaEELB entry (see VABBLD=Jnl in the DTIi3I 
Detail Entries section) . 

A TBDNC macro instruction causes no 
operation to be performed if the preceding 
PUT: 



TBUNC MACEO INSTEUCTION 

The format of this macro instruction 
(TEDHCate) is: 

I 1 1 

I Name | Operation jOperand 

i[name ] ITEUNC Ifilename 

1 I I 






The name of the file to which this macro 
instruction refers (name field entry on the 
DTFMT header entry line) is the only 
operand required. 



1. causes the last record of a block to be 
included in the output block; or 

2. causes the last record of a block to be 
moved from a work area to the output 
area for inclusion in the block before 
it is written on the particular output 
tape. 

In either case, the en'^ire block is 
written on tape. 



COMPLETION_MACEO_INSTEUCTICNS 

After all records of a file have been pro- 
cessed, that file must be deactivated. The 
macro instructions CLOSE and FECV (Force 
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End of Volume) are provided for this pur- 
pose. Note that the FEOV nacro instruction 
actually does not deactivate the specified 
file,, but Berely forces an end-of-volume 
condition. 

The need to deactivate a fil€ is indi- 
cated by an end-of-file (EOF) condition. 
The EOF condition is determined in various 
ways for different types of files and 
input/output devices as follows: 

I* Card JLnput files. Four cards with the 
characters /* in columns 1-2 are 
required by the IOCS to properly per- 
form end-of-file operations. 

2 • Tape input files wi th standard labels . 
The record following the tape mark is a 
label whose first three characters are 

EOF. 

3 • Tape files with standard, lajbels_that 

are read.. backwards. The record follow- 
ing the tape mark is a label whose 
first three characters are HDB. 

** • Tape input files without labels or with 
non-standard labels. A tape mark indi- 
cates an EOF condition. (The user's 
end-of-file routine must determine 
whether and end-of-file or an end-of- 
volume condition exists.) 

5. lll_out£ut_f iles. The user's program 
determines the end of a file. 

lS£lz2lzl!ile_£l2cessin3 

When EOF occurs in a card input file, the 
IOCS branches to the programmer's end-of- 
file routine. The address of his routine 
must be provided in the EOFAI)DE=name entry 
of the definition statement for the file. 

When EOF occuts in a tape input file 
with standard labels, the IOCS checks the 
E0F1 label and compares the block count 
recorded in the label with the block count 
that has been accumulated during proces- 
sing. An unequal condition is indicated to 
the operator who has the option to either 
terminate or continue the job. If user 
labels (UTL1-UTL8) are to be checked, the 
IOCS branches to the user's LABADDH routine 
when the checking of the E0F1 label has 
been completed. (Refer to the description 
of the LAEAEEE detail entry in the section 
nTFMT_Detail_En tries and to the section 
LBBET Macro Instruction.) After the check- 
ing of trailer label (s) has been completed 
the IOCS branches to the user's EOFADDR 
routine. 

If the tape input file has been read 
backward, the functions performed by the, 
IOCS are essentially the same. On reaching 
the tape mark preceding the first record of 



the file, the IOCS branches to the LAEAEER 
routine to check the user header labels 
(UHL1-DHL8) , if present, and then checks 
the HBR1 label. When these checks are com- 
pleted, the IOCS branches to the user's 
EOFAEDR routine. 

When EOF occurs in a tape input file 
without labels or with non-standard labels, 
the IOCS branches to the user's EOFADDR 
routine when the tape mark following the 
last data record is read. 

In his end-of-file routine, the program- 
mer may issue a CLOSE macro instruction to 
deactivate one or more files. The actions 
performed when a file is closed are 
described in the section CICSE Hacrg 
Instruction. 



End-qf-V olume P rocessing 

Some of the actions performed by the CLOSE 
macro instruction are also required when an 
end-of-volume (EOV) condition occurs while 
processing a tape file. 

The IOCS detects an EOV condition for 
standard-label input files by means of the 
characters EOV in a trailer label. For 
output files, the IOCS detects an EOV con- 
dition by sensing the reflective marker at 
the end of the output tape. For all other 
types of files, the IOCS has no means of 
detecting an EOV condition. 

During the processing of a tape file, an 
EOV condition can occur. This indicates 
that the next volume of the same file is 
required, either for reading more input 
records or for writing more output records. 

If FILAEL=STD has been specified for a 
file, the IOCS processes an EOV condition 
as follows: 

1. For input files, the IOCS (1) checks 
the block count, (2) branches to the 
user's routine that processes addition- 
al user labels, if such processing has 
been specified, and (3) performs the 
rewind option. The IOCS then processes 
the header label (s) of the next volume 
and makes the first record of the 
volume available to the problem 
program. 
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PJBeuli}3_l5£e_0ut£Ut_ Files under Open 
Macro Instruction. 
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CLOSE Macro Instruction 



The format of this macro instruction is 



I Name 1 Operation | Operand | 

l[name]lCLOSE Ifile 1 ,file2, . . .filen | 

The name of the file that is to be 
closed (assigned to it by the entry in the 
name field of a DTFSE or DTFMT header 
entry) must be specified as operand. Any 
number of files from one to sixteen may be 
closed with one CLOSE macro instruction. 

The CLOSE macro instruction is used to 
deactivate any file that has previously 
been made available by an OPEN macro 
instruction. The CLOSE macro instruction 
ensures proper handling of the file after 
all records have been processed. The func- 
tions performed depend on (1) the type of 
file and the type of input/output device 
involved and (2) the labeling technique (if 
applicable) . 

A file may be closed at any time by 
issuing a CLOSE macro instruction. 

ClosJn3_Card_and_Printer_Files 

For card and printer files, the CLOSE macro 
instruction makes the file unavailable for 
further processing. Specifically, the 
CLOSE macro instruction ensures that: 

1. records remaining in the output area 
upon completion of processing are 
printed and/or punched, 

2. all processed data cards remaining in 
the card feed path (not end-of-file 
cards) are selected into the appropri- 
ate stackers, and 

3. all pending interrupts for the closed 
file (s) have been handled. 

£iosiii5_ T a£e_ F i le s 

The functions performed when a tape file is 
closed depend upon whether it is an input 
or an output file. 



CLOS IN G_T AP J_IN PDI_IIL1 S : The CLOSE aacro 
instruction causes the input tape to be 
rewound according to the rewind option spe- 
cified in the DTFKT statement for the file. 
The IOCS then deactivates the file; no 
labels are read or checked. 

CLO£ING_I APE_COTPDT_FI LES : The CLOSE macro 
instruction causes the writing of any rec- 
ord or block of records that has not yet 
been placed into the file. If a record 
block is only partially filled, it will be 
written on tape as a short block. (When a 
file with short blocks is used as input, 
the ICCS handles these records properly.) 
No action by the programmer is required. A 
tape mark is written following the last 
record. 

If labels have not been specified, a 
second tape mark is written and the tape is 
rewound as specified in the ETFMT statement 
for the file. 

If standard labels have been specified 
for the file, the ICCS writes the trailer 
label after the tape mark. The trailer 
label includes the block count accumulated 
by the IOCS during the run and the header 
label information (except that HEE is 
replaced by EOF) . 
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Two tape marks are written at the end of 
a tape output file to indicate that no 
further data follows. If NCEWD has been 
specified for the file, the ICCS causes the 
tape to be lackspaced by one record. As a 
result, the second tape mark is overwritten 
if another output file is written on the 
same tape. 

JeoieniDg_ CI osed_ Piles 

If a CLCSE macro instruction has teen 
issued for a card or printer file, this 
file cannot fce reopened ty a sutseguent 
OPEN macro instruction. 

If further processing of a closed tape 
file is desired, the file can be reopened. 
If this is done, the user must be aware 
that the previous CLOSE for the file has 
caused the tape to be positioned in accor- 
dance with the EEWIND detail entry in the 
BTFCT statement for the file. Therefore, 
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to resume the processing of tape records at 
the point where the file was closed, 
BEWIHD=80BWB should be specified in the 
DTFHT statement. 

The first record read from the reopened 
tape file must be a file label if standard 
labels are specified for that file. If the 
tape file to be reopened is unlabeled or 
contains non-standard labels, the user must 
identify the first record read as a data 
record or a file label. 

When a multi-volume file is reopened and 
the DTFMT entry ALITAPE is included in the 
definition statement for the file, the IOCS 
continues to read from (or write in) the 
same volume that was used as input (or out- 
put) tape at the time the file was closed. 

lEOV_Macro_;inst ruction 

The format of this macro instruction (Force 
End-Of-Jolume) is: 



IHame |Operation lOperand 



Iname |FEOV 
I i 



{filename 



The name of the file to which this macro 
instruction refers (assigned to it by the 
entry in the name field on the DTFMT header 
entry line) is the only operand reguired in 
this macro instruction. 

This macro instruction is used for eith- 
er input or output files on tape to force 
an end-of-volume condition at a point other 
than the normal tape mark (input) or a 
reflective marker (output) . This indicates 
that processing of records on one volume is 
considered finished, tut that more records 
pertaining to the same file are to be read 
from or written on the following volume. 



If this macro instruction is issued for 
an input tape, the IOCS immediately causes 
execution of the rewind option selected by 
the user, provides for a reel change in 
accordance with the AITTAEE detail entry in 
the DTFMT statement for the file, and pro- 
cesses the header label (or labels) of the 
next volume as reguired. 



If this macro instruction is issued for 
an output tape, the IOCS causes the last 
block of records to be written, if neces- 
sary, followed by a tape mark. Then the 
IOCS 



causes the writing of the standard 
trailer label including the accumulated 
block count, and branches to the 
LABADDR routine, if this is specified; 



provides for a reel change in accor- 
dance with the SLTTJEE detail entry in 
the DTFMT statement for the file; and 



3. processes the header label (or labels) 
as reguired. 

An example for the use of the FEOV macro 
instruction is given below. 

If FILAEL=!JSTD or FILAEL=MC has been 
specified for a multi- volume input file, 
the IOCS has no means to detect an end-cf- 
volume condition. When a tape mark is 
detected, the IOCS transfers control to the 
user*s ECFADDB routine in which the user 
must determine the end of a volume. After 
the last block of a volume has teen read, 
the user must issue an FEOV macro instruc- 
tion to have the IOCS perform the end-of- 
volume functions in accordance with his 
detail entries. 



I 
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Operation j Operand 



CLOSE 



CMTBL 



i Bemarks 



filel ,file2, files,. ,, ,f ile16 



filenaine,Operation,n 
filename, Operation ,n ,m 

Po ss ible operation anp.njm) -operands 
BSF (backspace to tapemark) , no 

n (m)-operand 
BSE (backspace to inter-block gap) 

no n(m)-operand 
EHG (erase gap) , no n (in) -operand 
FSF (forward space to tape mark) , 

no n(m) -operand 
FSE (forward space to inter-block 

gap), no n(m) -operand 
REW (rewind tape), no n(m) -operand 
SUN (rewind and unload) ^ no 

n (m) -operand 

SK (skip) n; 1,2,.,,, 12 

m: 1,2, ...,12 

SP (form spacing) 

n: 0,1,2, or 3 



m: 0,1,2, or 3 



SS (stacker select) , n-operand 
required 



Dp to 16 files maj be closed 
with one CLOSE macro instruction 



Control 

applies to tape files only 

applies to tape files only 

applies to tape files only 
Applies to tape files only 

Applies to tape files only 

Applies to tape files only 
Applies to tape files only 



n causes immediate skip 

to specified tape channel 

m causes skip to specified 

tape channel after printing 

n causes immediate form 

spacing by specified number 

of lines 
m causes form spacing by 

specified number of lines 

after printing 
Applies to multi-stacker card input/ 
output devices only. The n-operand 
is the number of the stacker 
into which cards are to be selected. 



Figure 13. Summary of Imperative Macro Instructions, Part 1 of 2 
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I Operation | Operand 
CEDPS I ,worknaiBe,cardprintarea 



IBemarks 



EOH 



FEOV 



GET 



LBEET 



LOM 



OPEN 






PHTOV 



PDT 






RELSE 



TBDMC 



WAITC 



filename 



filename 



f lien ame, work nase 



n (n = 1 or 2) 



Force End of Volume, 
applies to Bulti-volume tape 
files only. 

Second operand laust be otaitted 

when no work area has been specified. 

Label Beturn. 

Bequired for return to IOCS fron 

the LABADDR routine. 



filename 



filel ,file2,. . , ,file16 



f ilename,n, address 



filename, wo rkname 



filename 



filename 



Card Print 

Absence of file-name operand is 
indicated by a comma, Eeguires 
CRDPRA and CRDPRLn DTFSB 
detail entries. 



Enter Overlap Mode. 
Applies to combined files for 
which a previous LOM macro 
instruction has been given. 



Leave Overlap Mode. 
Applies to combined files for which 
overlap mode has been specified. 
Dp to 16 files may be opened with 
one OPES macro instruction. 



Print Overflow. 

n is either 9 or 12 and denotes the 
channel indicator to be tested. The 
third operand specifies a branch 
address if a branch is desired on a 
overflow condition. A skip to chann 
1 is performed if the third operand 
has been omitted. 

Second operand must be omitted 
when no work area has been 
specified. 



n 
el 



Release. 

Applies to blocked record tape input 

files. 



-^ 



Truncate. 

Applies to blocked record tape output 

files. 

Required if (1) card files are 
processed in overlap mode and (2) a 
program using the IOCS is executed in 
several phases. 



! 



Figure 13. Summary of Imperative Macro Instructions, Part 2 of 2 
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COBTBOL STITEHBNIS 



If labeled tape files are to be processed, 
the lOCb requires two types of control 
statements which are used by the Job Con- 
trol program when the program is executed. 
These two types of control statements are 
(1) the Tape Volume Statement and (2) the 
Tape Label Statement. The format of each 
of these two statements is described below 

The volume and label statements provide 
the IOCS with the necessary label informa- 
tion to check labels for an input file or 
to create labels for an output file. For 
each labeled tape file, one volume state- 
ment and one label statement are required. 

For a given file, the volume statement 
must always precede the label statement 
that describes the file on the volume. 

louat_of_Volume_ Statement 



I Name |Operation 
I 1 



I Operands 



I// 

L 



I VOL 
.X 



SISnnn,XXXXXXX | 



The specified symbolic address of the tape 
drive used is the location of the first (or 
only) volume of the file. It is six char- 
acters in length. The name assigned to the 
file by the ETFiaT statement must be used in 



the file name field of the volume 
statement. 



Format of Tape Label. Statement 



1 Kame | Operation [Operands j 
I 1 4 , 

I// ITPLAB I'XXX .XXX» | 

The following information is required in 

the label information field: 

No. of Char's 

File Identification 17 

File Serial Number 6 

Volume Sequence Humter ^ 

File Sequence Number 4 

Generation Number (if used) 4 

Version Number {if used) 2 

Creation Date (bYYDDD) 6 

Expiration Date (blYDEE) 6 

The label information must be written as 
one character string enclosed in apostro- 
phes, i.e., an apostrophe before the first 
character and after the last character in 
the label information field. The precise 
format of tape labels is described in the 
SBL publication IBM_System/160_i3odel_20jt 
.?■§.£§„ if g.giggf,Pirng_ System,. Control and Ser- 
v ice_Jro.gr a ms , Form C2M-9C00. 
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BLOCKING OF RECOBDS 

Blocking of records is not possible for 
card and printer files. Blocking of tape 
file records offers the advantage that no 
unused gaps exist between individual rec- 
ords written on tape. A gap is provided 
between the last record of a block and the 
first record of the following block. This 
decreases the number of necessary tape 
starts and stops and permits the user to 
write more data on a tape. 

Blocking of records is accomplished by 
means of appropriate detail entries in the 
DTFKT statement for the particular file. 

If the records to be blocked are of 
fixed length, the user must include the 
following detail entries: 



1. 



EECFOBM=IIXBLK to indicate the record 
format. 



2. BLK£IZE=n to indicate the length of a 
block. 

3. EEC£IZE=n to indicate the length of the 
logical records. 

Note: If the DIFHT statement for the file 
does not include the SOEKA=YE£ detail 
entry, an IOBEG= (n) detail entry is 
required in addition to the three entries 
mentioned above. 

If the records to be blocked are of 
variable length, the following detail 
entries are required: 



1. 
2. 



BECFOBM=VABELK and 
BLKSIZE=n. 



Note: If the DIFMT statement for the file 
does not include the HOBKA=JE£ detail 
entry, the detail entries IOBEG= (n) and 
VAEELD=(n) are required in addition to the 
two entries mentioned above. 



If the output area is filled, the ICC£ 
causes all records currently in the output 
area to be written on tape as one block of 
records. In addition, the value in the 
lOBEG register is reset to the starting 
address of the output area. Note that the 
OPEN routine places the starting address of 
the output area into the ICEIG register. 



If the user builds his 
area a POT macro instruct 
reccrd in the work area t 
the output area. In addi 
checks to determine if th 
filled. If the output ar 
the ICC£ returns control 
gram and the next PDT mac 
causes the record now in 
be moved into the next av 
space in the output area, 
area is filled, the IOC£ 
in the output atea, inclu 
was moved into the output 
macro instruction, to be 
one block of records. 



EEBLOCKING OF BECOBDS 



records 
ion caus 
o be mov 
tion, th 
e output 
ea is no 
to the m 
ro instr 
the work 
ailable 

When t 
causes a 
ding the 

area by 
written 



in a work 
es the 
ed into 
e IOCS 

area is 
t filled, 
ain pro- 
uction 

area to 
record 
he output 
11 records 

one that 

the PUT 
on tape as 



I 



Records are deblocked by including detail 
entries in the DTFMT statement for the file 
as described below. 

If the records to be deblocked are of 
fixed length, the detail entries required 
are : 

1. BECFOEM=FIXELK to indicate the record 
format. 

2. ELK£IZE=n to indicate the length of a 
block. 

3. BEC£IZE=n to indicate the length of the 
logical records. 



If the user bui 
output area the va 
is used to address 
able in the output 
instruction is iss 
has been built. T 
the output area is 
area is not filled 
value in the lOEEG 
of bytes contained 
fore, the lOBlG re 
address of the nex 
where the user can 



Ids his records in the 
lue in the lOEEG register 
the record space avail- 
area. A PDT macro 
ued each time a record 
he IOCS then checks if 

filled. If the output 

, the IOCS increases the 

register by the number 

in the record. There- 

gister points to the 

t available record space 

build his next record. 



Ncte: If the DIFMT statement for the file 
dees not include the HCBKa=YES detail 
entry, an ICEEG= (n) detail entry is 
required in addition to the three entries 
mentioned above. 

If the records to be deblocked are of 
variable length, the detail entries 
required are: 

1. EECFORM=VABBLK and 

2. BLKSIZE=n. 
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Sgte: If the DTFMT statement for the file 
does not include the WORKA=YES detail 
entry, an IOEEG=(n) detail entry is 
required in addition to the two entries 
mentioned above. 

after a GET has caused the entire block 
of records to be read into the input area, 
the first logical record of the block is 
immediately available for processing (eith- 
er in the input area or in the work area) . 
The next GET for this file will make the 
next logical record available for proces- 
sing. This function is repeated until the 
last logical record of the block has been 
made available for processing. 



this input/output operation is a tape re- 
wind operation on another tape drive or a 
print operation on the 1^03 printer. 

One Input/Cutput Area and Cne Work Area 



If the processing of 
work area rather tha 
area, the programmer 
YES entry in the DTF 
for the file. (For 
the use of a work ar 
Also, he must define 
program and assign a 
is then specified as 
whenever he issues a 
instruction for the 



records is done in a 
n in the input/output 

must include a HCBKA= 
SE (DTFMT) statement 
card and printer files, 
ea is mandatory.) 
a work area in his 
name to it. That name 
the second operand 
GET or a PUT macro 
file. 



INPUT/GDTFDT-HOHK AREA COMBINATIGHS 

The user must define, in his main source 
program, an area into which input data can 
be read and from which output data can be 
written by the IOCS routines. The name of 
this area must be used as the specification 
in the lOAEEA detail entry (or entries) for 
the file. When a work area is not speci- 
fied, all records are processed in the 
input/output area(s). 

For a particular file, the user can spe- 
cify one of the following input/output-work 
area combinations: 

1. One inpu^/output area. 

2. One input/output area and one work area. 

3. Two input/output areas (for tape files 
only) . 

4. Two input/output areas and one work area 

(for files associated with the IBH 2501 
Card Reader, or for tape files) . 



The size of an inp 
equal to the length o 
be processed. The si 
should be equal to th 
dual record. However 
unblocked records or 
format are specified, 
take into considerati 
specified in the BLKS 
defining his work are 
description of the BL 
the section DTFMT Det 



ut/output ar 
f the longes 
ze of a work 
e length of 
, if variabl 
records of u 
the program 
on the numfce 
IZE detail e 
a (s) . (Eefe 
KSIZE detail 
ail Entries. 



ea must be 
t block to 

area 
an indivi- 
e-length 
ndef ined 
mer must 
r of bytes 
ntry when 
r to the 

entry in 
) 



On e In put/Output, Area 



Specifying an input/output area without a 
work area is permitted for tape files only. 

When a GET or a POT macro instruction is 
given for a file while another input/output 
operation is executed, the IOCS enters a 
waiting loop to wait for the completion of 
this input/output operation, except when 



Note: Input/Output areas for tape files 
must not be used as work areas. 

When a GET macro instruction is given 
for a file that uses a work area a record 
is moved from the input area into the work 
area. When a EDT macro instruction is 
given, a record is moved from the work area 
into the output area. 

For card files, the combined use of a 
work area with one I/O area permits the 
IOCS to overlap an input/output operation 
with processing and/or with another input/ 
output operation. The same applies for 
tape files if a Submodel 5 is used and the 
EWC feature is specified. This increases 
system throughput, i.e., it increases the 
amount of records processed within a given 
time. 

For tape files, the use of a work area 
provides the advantage of increased system 
throughput only if the program utilizes 
card and print devices (excluding the lEM 
1103). If a GET is issued for a tape file 
that uses a work area specified, the IOCS 
performs as follows: 

1. The next record in the input/output area 
is made available for processing by mcv- 
ing it into the work area. 



If the record 
is the last on 
input/output a 
instruction ca 
actual device 
will be execut 
available. Dn 
executed proce 
CED time does 
execution of t 
the next GET m 
the first reco 
program enters 



moved into the work area 
e available from the 
rea, the GIT macro 
uses, at the same time, an 
request to be issued that 
ed as soon as CED time is 
til this request can be 
ssing is continued. If 
not become available fcr 
he device request before 
aero instruction requires 
rd of the next block, the 
a waiting loop. 



If a work area is not used, the next 
block of records is requested by the GET 
macro instruction that requires the first 
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Record 
Format 
(Blocked or 
Unblocked) 

-+ 



Unblocked 



Blocked 



Humber of 
I/C Areas 



T r- 

Separate | 

Hork I 

Area | 

I 



Amount of Effective Overlap 



no 



I No overlap 



yes lOverlap processing of each record 
1 (Record move required) 

no lOverlap processing of each record 

I (Ho record move required) 
-f- 



yes lOverlap processing of each record 

I (No advantage to specify a work area) 



no 



I No overlap 



yes lOverlap processing of first or last record in each block 
lOverlap processing of full block 



no 

^ 



yes lOverlap processing of full block 

I (No advantage tc specify a work area) 



Note: Overlap given is the maximum achievable. 

Figure 14. Summary of Achievable Overlap of Processing and Input/Output when 
a Submodel 5 is used and the Bead/Compute, Krite/Compute Overlap 
Feature is employed. 



record of the new block. If the CPU is 
busy servicing another input/output device 
that does not permit concurrent tape input/ 
output, processing is not possible because 
the record to be processed is not yet 
available. The program then enters a wait- 
ing loop until the current input/output 
operation is completed. 

To summarize, the use of a work area 
causes the device request for a new record 
block to be given already at the time the 
last record of the preceding block is made 
available for processing. If no work area 
is specified, the device request for a new 
block is not issued until the first record 
of the new block is required. 

If a PUT macro instruction is given 
while the CPU is busy servicing another 
input/output device, the record in the work 
area is moved into the output area. If 
this was the last record to be moved into 
the output area, this PUT macro instruction 
will also cause a device request to be 
issued that will be executed immediately 
after completion of the current input/ out- 
put operation. Until the request can be 
executed, the CPU can perform processing on 
the first record of the next block. If a 
work area is not specified, the program 
must enter a waiting loop until the current 
input/output operation is completed. Dur- 
ing this time, no processing is possible 
and processing time is lost. 



When a work area is used, the user can 
do all his processing in a predetermined 
area. Also, an lOREG register is not 
required. These are further advantages 
offered by the use of a work area. 

?¥°...|j(?£yt/.Qutput Areas 

The use of two input/output areas without a 
work area is only permitted for tape files. 
The user can only take advantage of speci- 
fying a second I/O area when he uses a Sub- 
model 5 and the program makes use of the 
read/compute, write/compute overlap 
feature. 

a . Input . 

The combined use of two input/ 
output areas allows the overlap of 
the processing of one block with 
the reading of the next one. Hhen 
the last logical record of a block 
in one area has been processed, the 
reading of the next block from tape 
into the same area is overlapped 
with the processing of the block in 
the other area. 

b. Output. 

The combined use of two input/ 
output areas allows the overlap of 
the writing of one block with the 
building of the next one. When one 
output area is full, the block is 
written onto tape. Meanwhile, 
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j Record Format 


-r 

1 Number oj 
1 Input/ 
1 output 
1 Areas 

., i. _ _, ____ 


Y- 

E I 


Work Area 

Specified 




ICBEG 
Required 


— p. 
? 1 


VAEELE I 
Required? | 

1 


— - -- — 1 

BECSIZF={n) 1 

Required? 1 

1 

1 

J 


1 Fixed Blocked 
1 Fixed Blocked 


1 1 or 2 

1 1 or 2 
1 




Ho 
Yes 






Yes 

No 




1 
No 1 
No 1 




No 
No 


^ 

J 


1 Fixed Unblocked 
1 Fixed Unblocked 
1 *Fixed Unblocked 
1 Fixed Unblocked 


1 1 

1 1 or 2 
1 2 
1 2 


-—X- 


No 
Yes 
Yes 
No 






No 
No 
No 
Yes 


_i_ 


No 1 
No 1 
No 1 
No 1 




Ho 
No 
Ho 
No 


1 Variable Blocked 
1 Variable Blocked 


1 1 or 2 
1 1 or 2 


T^ 


Ho 
Yes 




1 


Yes 

No 


— +- 


Yes** 1 

No 1 

_ J. 




No 
No 


1 
J 


1 Variable Unblocked 
1 Variable Unblocked 
1 Variable Unblocked 


1 1 
1 1 or 2 
1 2 


J.- 


No 
Yes 

Nc 




1 

1 


No + 

No 

Yes 


No 1 
No 1 
No 1 




Ho 
Ho 
No 


1 
J 


1 Undefined 
1 Undefined 
1 Undefined 


1 1 
1 1 cr 2 
I 2 


-. jL ., 


No 
Yes 

No 


1 
1 
1 
1 

X- 

tbe 


No + 

No 

Yes 

IBM 2501 


— X_ 

in 


■ -r 
No 1 
No 1 
No 1 




Yes 
Yes 
Yes 


J 


1 ♦Only for card-inp 
1 **Output files only 
1 +Eeguired if read 


ut files to 

• 

backward is 


be read by 
specified. 


overlap mode 


• 










Figure 15. Register Requirements 



another block is built in the other 
area. Thus, a maximum degree of 
overlap is obtained. 

Two Input/Outp ut A reas a.nd„,One.ggrk_ Area 

The use of two input/output areas together 
with a work area is permitted only for card 
input files that are to be read by the IBM 
2501 Card Reader in overlap mode, or for 
tape files. 

1. For the IBM 2501 Card Reader: This 
area combination permits the IOCS to 
maintain the maximum card reading speed 
of the IBM 25C1. 

2. For tape files: 

The user can only take advantage of 
specifying a second I/O area when he 
uses a Submodel 5 and the program makes 
use of the read/compute, write/compute 
overlap feature (see also Figure 14) . 
The information contained in the pre- 
vious section. Two „,Input/Output,, Areas 
(subsections a and b) , should also be 



considered when using two input/output 
areas and a work area. 

Ji63is[ter_Re5uirements 

The record format in conjunction with the 
input/output-work area combination used 
determines whether none, one, or two regis- 
ters (lOREG, VARBLD and/or EECSIZE) must be 
specified. Figure 15 indicates when it is 
necessary to specify a register. 



DTF BLOCKS 



For e; 

progr 

built 

phase 

refer 

such 

fied 

used, 

Figur 

of in 



ach ta 

am tha 

in ma 

of th 

red to 

inform 

rewind 

the a 

e 16 s 

format 



pe file to be processed in a 
t uses the ICCS, a table is 
in storage during the generation 
e assembly. This table is 

as the DTF block. It contains 
ation for the file as the speci- 

function the type of labels 
ccumulated block count, etc. 
hows the layout of and the type 
ion contained in the DTF block. 
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I BYTE 

J 

0-1 



f + Y- 



4-5 



6-7 






1_. 



8-9 



10-11 



12 



BIT 



CONTENTS 



address of DTF Block — Id binary notation. 



OPEN Rewind Option — command byte of CCW used when the file is opened: BEW 
or NOP. 



CLOSE Rewind Option — command byte of CCH used when the file is closed: 
HEW, RDN, or NOP. 



Residual Count — in binary notation, 



, 



Onit Status Bytes — reserved for IOCS internal use; the user is not per- 
mitted to change the bit configuration of these two bytes. 



Attention 
Status Modifier 
Control Unit End 
Busy 

Channel End 
Device End 
Unit Check 
Unit Exception 



Incorrect 
Wait Bit 
In Error 
Wait for 
Reserved 
Device En 
Accept In 
Reserved 



Record Length 

Recovery 

CPU Availability 

d Significant 
put/Output Error 



+ + 



Logical U 
(symbolic 
unit tabl 
of the fo 



OC tbrou 
(In incr 
of two p 
symbolic 
dress) 



nit Displacement — the displacement of the logical unit block 
device address) with reference to the begin address of the logical 

e in binary notation. Ihe contents of these two bytes may be one 

llowing (shown in hexadecimal notation) 
04 for SYSIFT 
06 for SYSOPT 

gh 2A for SYSCCO through SYS015, respectively. 

ements 

er 
ad- 



The user is not permitted to change the bit configuration of these two 
bytes. 

Address of CCW. 



Not used. 
Type of File — 
FEOV Switch — 
EOF/EOV Indicator — 
CEEN Indicator — 
Alternate Drive Switch 
Not used 
Not used 



1 = 


Inf ut ; 


= Output 


1 = 


Yes; 


= No 


1 = 


EOF; 


= ECV 


1 = 


Open 


= Closed 


1 = 


Yes; 


= No 



Figure 16. Layout of and Type of Information Contained in the DTF Block, Part 1 of 2 
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I 1 r 

BYTE IBIT 

4 



13 



14-15 
16-17 



h- 





♦43-91 



CCHIEKTS 



Standard Labels Indicator — 
Auxiliary Labels Indicator -■ 
Bewind Unload Switch — 
Rewind Option Indicator — 
Bead Option Indicator — 
User LflBADDR routine — 
Tape Mark Option — 
Not used. 



= Yes; = No 

= NSID; = No labels 

= Yes; = No 

= HBRD; = BEH 

= Back; = Forward 

= Yes; = No 

= No; = Yes 



j 



EOF Address — address of user-routine in binary notation. 

Alternate Unit Address Displacement — the displacement of the logical unit | 
block (symbolic device address) for the specified alternate tape drive. The | 
displacement is given with reference to the begin address of the logical | 
unit table. j 

CCW for Set Tape Mode Operation. I 



CCH for Tape Input/Output Operation. 



Accumulated Block Count — in packed decimal format. 



LABADDE Address — address of user-routine in binary notation. 



1 



File Name — the symbol specified in the name field of the ETFKT statement | 

for the file. I 

Standard Label — the contents of fields 3 through 10 of the standard file | 

label. I 



♦This type of information is included only in the DTF blocks of files for which stan- | 
dard labels have been specified. I 



• Figure 16. Layout of and Type of Information Contained in the ETF Block, Fart 2 of 2 



There are two methods by which the user 
can obtain access to individual bytes of 
the DTF block for a file: 



1 



The first byte (byte 0) of the DTF 
block is addressable by using the file 
name as a symbolic address. For 
example, to refer to the CCW for input/ 
output operations the user must specify 
the file name+24 in his instruction. 



If the inst 
a location 
preceded by 
that refers 
15 contains 
byte (byte 
this case, 
ister 15 as 
appropriate 
access to t 
block. 



ruction 

within t 
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her file, 
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e DTF bloc 
rammer may 
gister and 
ement to o 
ed byte in 



refer to 
ck is not 
truction 
register 
e first 
k. In 

use reg- 

write an 
btain 

the DTF 



Access to the information contained in 
the DTF block for a file permits the user 
to test and/or modify the contents of the 
DTF block. He may, for example, test the 



accumulated block count on a tape read or 
write error and correct it after the error 
recovery. 



DEVICE EBBOB EECOVEBY 

PiiSched-Card_E3ui£ment_Errors 

When errors (read checks, feed checks, 
etc.) occur on punched-card eguipment, the 
IOCS discontinues the execution of the pro- 
gram to allow the operator to take correc- 
tive action. An error indication is dis- 
played on the CEU console to identify the 
type of error and to indicate the required 
restart procedure. 

Ilie_Error_Eou tines 

The IOCS routines provide that on tape read 
errors the tape is backspaced and re-read 
ICO times before the block is considered an 
error block. The IOCS routines further 
provide that any error which can not te 
corrected is indicated to either the main 
program or the operator. Eefer to the 
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description Oi the ERBOPT detail entry. 
Indication to the operator is by means of a 
display on the CPU console. This display 
indicates the type of error and the device 
address. 

If a tape write error occurs, the IOCS 
causes the tape to be back-spaced by one 
block, the error block to be erased, and 
the output block to be written on a new 
section of tape. The IOCS nakes a total of 
10 attempts to rewrite a block as described 
above. If the tenth attempt does not 
result in a correctly written output block, 
a programmed halt occurs. 

REGISTER OSAGE 



Programming System and the Basic Operating 
System IOCS use registers and 1 for this 
purpose in the laEADDB and other routines 
such as EBROPT and HLREBR. 



IOCS aSSEKBLi 

Both the IOCS portion and the user written 
program instructions are assembled in one 
and the same run. Figure 17 shows the 
arrangement of the input cards for a source 
program using the IOCS. 



The programmer may freely use any or all of 
the registers 10 through 13. 

Registers 8, 9, 1U, and 15 are not 
readily available to the programmer for 
reasons explained below. 

Registe rs 8 and_9 are used by the IOCS to 
communicate with the LABADDB routine (see 
iimpB^ame) . Before branching to that 
routine, the IOCS saves the values that are 
contained in these registers. The two reg- 
isters are restored to their original 
values if the programmer uses the LBHET 
macro instruction to return to the main 
program. 

R eg isters 14 and 15 are used by the IOCS 
imperative macro instructions (GET, PUT, 
etc) . If the programmer uses one or both 
of these two registers in his program, he 
must make sure their contents are no longer 
required before he issues an IOCS impera- 
tive macro instruction. He must save these 
registers if he requires their contents 
later in his program. 

When an lOCS-controlled branch to a 
user- routine (ERROPT, LABADDR, PFXIT, 
RFXIT, SQXIT, or HLERR) occurs, the con- 
tents of registers 14 and 15 must not be 
destroyed. If the user desires to issue an 
IOCS macro instruction in his routine, he 
must save the contents of the two registers 
before this macro instructicn is executed. 
He must restore the contents of the two 
registers to their original values before 
he returns control to the IOCS. 

Transit ion_Conside rations. If the user 
anticipates transition to a higher System/ 
360 model, he must be aware that the Basic 
Programming Support or the Basic Operating 
System Supervisor do not permit the pro- 
grammer to use registers 12 and 13. 

In the LABADDR user routine, the Model 
20 IOCS uses registers 8 and 9 as communi- 
cation registers (see the description of 
the LABADDR=name detail entry) . The Basic 




Source (Problem) 
Program Cards, 
including IOCS 
Imperative Macro 
Instructions 

DTFEN Card 



Definition Statements 
(for three files) 



Job Control Cards 



Figure 17. Arrangement of Source Program 
Cards Using the IOCS 

El^ci ncs tics for Source Programs Using the 

iocs" 

During the assembly of a program using the 
IOCS, the IOCS portion of the program is 
subject to extensive checking for format 
errors. This checking is performed in two 
steps as follows: 

1 . during each macro phase of the assembly 
— i.e., during the generation of a 
routine that is to replace a macro 
instruction in the problem program and/ 
or the generation of DTF routines; and 

2. during the assembly of the problem 
program. 

The checks performed during step 2 are 
those that are normally performed by the 
Assembler. 



62 IBM System/360 Model 20 TPS IOCS 



EBB 
EBB 
EBB 
EBB 
EBB 
EBB 
EBB 
EBB 



AEDB2 STMNT 


SOURCE 


STATEMENT | 


0362 


FILE 


DTPKT DEVaEBE=SIS001, | 


0363 




EOFSDDR=NAME, | 


0364 




FIIABL=HC, 1 


0365 




I0AR;EA1=NAME, | 


0366 




IOBEG=nO) , 1 


0367 




LABAiBDR=NC, j 


0368 




BECFCBM=FI]{ELK, | 


0369 




TPMARK=NO, 1 


0370 




TYEEFLE=INEI]T, j 


0371 




VARBLD=SYMBOL, 1 


0372 




WOBKa=lES 1 


0373 


MNCTE 


TAPEMARK OPTION SPEC'D FOR INPUT FILE | 


0374 


MNOTE 


VABBLD SPEC'D BUT NOT REQUIRED | 


0375 


MNOTE 


NO BECSIZE SPEC'D | 


0376 


MNOTE 


lOBEG SPEC'D WITH UOEKA | 


0377 


MNOTE 


IMPEOPER BLKSIZE 1 


0388 


MNOTE 


INVALID DEVADDE SPEC | 


0379 


MNOTE 


LABADER SPEC D FOR A NO LABEL FILE | 


0380 


MNOTE 


GENERATION TERMINATED | 



Note: Continuation punches (column 72) are ret shown 



Figure 18. Example of MNOTE Diagnostic Messages 



Checleina_Durina_the_Mjcro_Phase. The IBM- 
suppiied IOCS macro definitions include 
conditional-assembly instructions that 
cause the user-specified operands and DTFMT 
(DTFSB) detail entries to be checked. When 
an error is detected, an appropriate MNOTE 
diagnostic message is printed in the pro- 
gram listing. Figure 18 shows an example 
of MNOTE diagnostic messages that were 
printed as a result of incorrect and/or 
inconsistent detail entries to a DTFMT 
statement. The MNOTE diagnostic messages 
describe the type of error (s) detected dur- 
ing the macro phase of the assembly. 



When an error is detected, diagnosing 
continues until it is completed for all of 
the macro instruction operands and detail 
entries involved. However, the generation 
of source language coding for the macro 
instruction (definition statement) that 
contains the error is suppressed. 

Some errors cause the printing of more 
than one MNOTE diagnostic message. For 
example, assume that FILABL=STAND has been 
specified for a file with standard labels. 
Further assume that a label exit routine 
has been specified for this file. As a 
result of the erroneous FILABL detail 



entry, the following two MNOTE diagnostic 
messages are printed. 



MNOTE 



MNOTE 



lEEEOIEB FILAEL SPEC'D 



SPEC'D WITH STAND 
LAEBL FILE 



The second of these two KNCTE diagnostic 
messages is printed because a LABADDE 
detail entry is only permitted if 
FILABL=STD has been specified for the file. 
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Three examples of error indications hy 
the Assembler are given below. These 
examples explain some of the error condi- 
tions that are detected by the Assembler 
during the assembly of the problem prograi 
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1. 



2. 



3. 



Assume that I0AREA1 
specified in the de 
for a file and that 
the prograamer has 
a definition of the 
this case, all refe 
IOCS macro instruct 
tions in the proble 
tified as undefined 



=ODTPDT has been 
finition statement 

in his program, 
erroneously omitted 
symbol OUTPUT. In 
rences to OUTPUT in 
ions and/or instruc- 
m program are iden- 
-symbol errors. 



An undefined-symbol error occurs if the 
program calls for an IOCS function that 
is not available for the referenced 
file. For example, a BELSE macro 
instruction referring to a file named 
PAYROLL is issued in a problem program 
and this file has been defined as an 
input file that consists of unblocked 
records. Since the RELSE routine is 
only available for blocked-record 
files, the generated reference to the 
RELSE-routine entry point is identified 
as an undefined-symbol error. A simi- 
lar situation occurs if a TRUNC macro 
instruction is issued for an output 
file that is to consist of unblocked 
records. 

Undefined-symbol errors may occur if 
the generation of an IOCS routine has 
been terminated because of an error 
condition during the macro phase of the 
assembly. In this case, references are 
made to non-generated routine entry 
points, and all of these references are 
identified as undefined-symbol errors. 



RESTRICTIONS 

When writing his own routines, the program- 
mer has to observe the following; 

1. He must not use any names starting with 
the letter "I" because all names used 
by the IOCS start with this letter. 
This is to eliminate the possibility of 
multiple-defined names. 

2. He must not use file names that are 
longer than seven characters (refer to 
Hgader Entries) because the eighth 
character position is required by the 
IOCS. 



3. To avoid multi-definition of names, the 
first seven characters of names used by 
the programmer should not be identical 
with the first seven characters of 
names given to files. The assembler 
derives the entry points to the ICCS 
routines by adding a character to the 
end of the file name. 



Examplej If REAECEE has been assigned 
as name to an input file, the program- 
mer should not use names such as 
READCREA, READCRDB, etc. in his source 
program. 



The name assigned to a file to be pro- 
cessed by the ICCS routines must net be 
used in the name field of a statement 
in his program. 



It is not permitted to give an XIO or 
an SPSW instruction as this would cause 
an unexpected interrupt and thus inter- 
fere with automatic scheduling of 
input/output operations by the ICCS. 



Use of the tETCH Eacro Instruction in 
lIoaraffl£_Usln3_the_ICCS 

When a program (or a program phase) that 
includes input/output routines for new 
files is loaded, the programmer must ensure 
that all files used in the preceding pro- 
gram have been closed. If any of the files 
so closed are required during the newly 
loaded program, such files must be rede- 
fined and subsequently opened in the new 
program. 

Bote that the operator is required to 
run-out the cards in the associated card 
input/output device if a card file is to be 
closed for the purpose of loading a new 
program. Also, a second or subsequent pro- 
gram cannot be loaded from a card input 
device in which data cards were read during 
any of the preceding programs. 



! 
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The Model 20 IOCS is closely patterned therefore be aware that programs using the 

after the Basic Programming Support IOCS Model 20 IOCS require some modification 

and the Basic Operating System IOCS. Since prior to generation by the other /360 

the Model 20 IOCS is designed to support Systems. 

card and printer input/output devices that 

are unique to the Model 20 and to achieve 

optimum performance of all deviceis, some all control cards and labels used and/or 

macro instructions and DTFSE entries are required by the Model 20 IOCS as well as 

not identical to those of the other sys- card and tape data sets created under con- 

tems. Users who anticipate transition from trol of the Model 20 IOCS are fully upward 

Model 20 to other System/360 models should compatible. 
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PROGRAMMING EXAMPLE 1 



This example (Figure 19) illustrates the 
files and main-storage area assignments for 
two tape files and one card file. It is a 
simplified order and inventory job in which 
a master tape is updated and written onto a 
new tape and a card file of detail orders 
is processed. The fol] owing assumptions 
are made; 

• The old master inventory tape contains 
quantity on hand and unit price in addi- 
tion to the identifying information. 

• The card file reflects quantities 
ordered. It is to be completed with 
quantity available for shipment, unit 
price, and the extension of quantity 
shipped times the unit price. 

• The new master inventory tape reflects 
the decrease in quantity on hand due tc 
the current orders or an increase when 
items are returned. 

The paragraph numbers of the following text 
correspond to the coded numbers in Figure 
19. The illustration shows this setup: 

1. Job Control cards to indicate to the 
Basic Monitor program the type of job 
(assembly run) to be executed. 

2. Definition statements to define the 
three files. 

a. Old master tape file. This is an 
input file to be read forward. It 
contains standard volume and file 
labels and additional user 80- 
character file labels. It is a card- 
image file with a blocking factor of 
5. Register 10 is assigned for 
locating individual records in the 
input area. 

b. New master tape file. This is an 
output file with the same character- 
istics as the input file. Register 

1 1 is assigned for locating the next 
available output-record area. 

c. Detail card file. This is a combined 
file used to update input records 
from the old master tape file. The 
cards are in the primary feed of an 
IBM 2560 MFCM and are read in the 
read station of that machine. 

d. End of the three file definition 
macro instructions. The user's 
source program follows this 
statement. 



3. Sample instructions to open files and 
locate master records that have current 
activity. This illustrates the 
following: 

a. The registers used in the program 
are defined by means of DSING 
instructions. Register 12 is used 
as base register and the address of 
the next instruction is loaded into 
this register. The use of registers 
10 and 1 1 is explained later in this 
section. 

b. fill files to be processed by the 
IOCS must be opened. 

c. A GET for an unblocked record to be 
processed in a work area causes the 
record to be transferred from the 
input/output device to main storage. 
This makes the record available to 
the problem program. 



d. 



e. 



The first GET for a 
blocked file causes 
transfer of the tlo 
the input/output de 
input/output area, 
the address of the 
the specified ICIEG 
succeeding GET caus 
the currently avail 
placed in the lOREG 
may or may not caus 
data. 



record in a 

the physical 
ck of data from 
vice to the 

It also places 
first record into 

register. Each 
es the address of 
able record tc be 

register, and 
e a transfer of 



! 



The master and detail item numbers 
are compared with each other to 
determine if either (1) a master 
record is missing or a card with a 
new detail item number has been 
read, or (2) the master record is tc 
be updated, or (3) the master record 
is to be written unchanged on the 
output tape. 

To address any field within the 
CKSTE input record being processed 
(AREA1), register 10 has been 
assigned by the Assembler as base 
register because this register pro- 
duces the lowest displacement. 
Since register 10 has also been spe- 
cified in the ICEEG entry for the 
OMSTR file, the IOCS automatically 
loads the register and changes its 
contents to point to the begin 
address of the record being pro- 
cessed. When this programming tech- 
nique is used, the programmer need 
not specify a base register in 
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f. 



instructions referring to fields of 
the OMSTH input record currently 
being processed. 

The same programiing technigue is 
used to address the NMSTE output 
records. However, register 11 has 
been assigned by the Assembler as a 
base register for the addresses of 
the fields within the NMSTR record 
being processed (AREA2) . 

The UPDATE routine is entered when- 
ever it is determined that a record 
from the OMSTR input file requires 
updating . 



When output file 
register, the re 
ized by the OPEN 
an output file f 
was not specifie 
address of the n 
area to be place 
lOEEG register, 
within storage, 
the data to the 
may not occur. 



s specify an lOBEG 
gister is initial- 
routine. A PUT to 
or which a work area 
d merely causes the 
ext available record 
d into the specified 

No data is moved 
and a transfer of 
output device may or 



The EBBOE routine is entered when 
either a master record is missing or 



a new detail number has been 
detected. In this routine, the user 
may build a record for inclusion in 
the new master file. 



U. User routines for processing additional 
standard labels. 



5. All files that have been opened must be 
closed. This is normally done in an 
end-of-file routine. 

6. Assembler instructions to define the 
input and output areas for the three 
files. 

a. Two input/output areas and one work 
area are reserved for detail card 
records. Because these are single 
unblocked records, the individual 
fields within the records may be 
defined along with the allocation of 
the work area as shown. 

b. An input/output area is reserved for 
each of the two master files. Note 
the use of the zero-duplicaticn fac- 
tor to define fields within logical 
records of the CESTB input file. 
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PROGRAMMING EXAMPLE 2 



The following simple example (Figure 20) 
illustrates how the read/compute, write/com- 
pute overlap feature is used, in connection 
with two 1/0 areas and a work area. 

A maximum degree of overlap is achieved 
as follows: 

Input. The combined use of two input 
areas allows the processing of one block to 
be overlapped with the reading of the next 
one. When the last logical record of a 
block in one area has been processed, the 
reading of the next block from tape into 
the same area is overlapped with the pro- 
cessing of the block in the second input 
area. 

Output. The combined use of two output 
areas allows the writing of one block to be 
overlapped with the building of the next 
one. When one output area is full, the 
block is written onto tape and, at the same 



time, another block is built in the second 
output area. 

The job being done is basically the same 
as in the previous example. An old master 
inventory tape contains quantities on hand 
together with identifying information. A 
card input file reflects quantities received 
or dispatched (only the first 20 columns of 
each card contain data) . The new master 
output file contains the resulting new 
quantities. A list is printed of all rec- 
ords on tape; any changed quantities are 
marked with an asterisk in the last print 
position. 

For simplicity, no error routine is 
included. The program halts if a card is 
read for which there is no corresponding 
tape record, or if the end-of-tape has 
been reached before the last card has 
been processed. When the last tape record 
has been processed, the job is completed. 
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GLOSSARY 



Address . 

1. An identification, as represented by a 
name, or number, for a register, loca- 
tion in storage, or other data source 
or destination. 

2. Loosely, any part of an instruction 
which specifies the location of an 
operand for the instruction. 



Allgcatg. To assign storage locations or 
areas of storage for specific routines, 
portions of routines, constants, data, etc. 

Alphameric. A generic term for alphabetic 
letters, numerical digits, and special 
characters. 

A scend ing Order. A sequence of records 
such that the control fields of each suc- 
cessive record collate equal to or higher 
than those of the preceding record. 

Assemble. To prepare an object-language 
program from a symbolic-language program by 
substituting machine operation codes for 
symbolic operation codes and absolute or 
relocatable addresses for symbolic 
addresses . 

Basic.. Hon itor . The main control program. 
Available in a card, a tape, and a disk 
version. Resident in main storage when 
control required. Loads programs into main 
storage and causes their execution. 

Binary. 

1. A characteristic or property involving 
a selection, choice, or condition in 
which there are two possibilities. 

2. The number representation system with a 
base of two. 

Bit. A binary digit. 

Blank Character. Any character or charac- 
ters used to produce a character space on 
an output medium. 

B lock (re cords) . 

1. To group records for the purpose of 
conserving storage space or increasing 
the efficiency of access or processing. 

2. A physical record so constituted, or a 
portion of a telecommunications message 
defined to be a unit of data 
transmission. 

Branch . 

1. To depart from the normal sequence of 
executing instructions in a computer. 

2. A machine instruction that can cause a 



departure as in (1) . Synonymous with 
' transfer* . 

Buffer (Program Input/Out put) . A portion 

of main storage into which data is read, or 
from which it is written. 

Byte. A sequence of adjacent binary digits 
operated upon as a unit. 

Card Stacker . A mechanism which stacks 
cards in a pocket after they pass through a 
machine. 

Ce ntr al_P rocessin3_Dni t . A unit of a com- 
puter that includes circuits controlling 
the interpretation and execution of 
instructions. 

Checkpoint. A point in a program about 
which sufficient information is stored to 
permit restarting the problem from that 
point. 

Column_Einary . Pertaining to the binary 
representation of data on punched cards in 
which adjacent positions in a column corre- 
spond to adjacent bits of data. 

Command. An instruction in machine 
language. 

Constant. A fixed or invariable value or 
data item. 

Control Program. A set of programs which 
provide the management functions necessary 
for continuous operation of a computing 
system. 

Control ..Statement. Any of the statements 
in the input to a specific job that define 
the requirements of the job, its options, 
or control its actions. 

Counter. A device such as a register or 
storage location used to represent the 
number of occurrences of an event. 

CPU. See Central Processing Dnit. 

C yc le. 

1. An interval of space or time in which 
one set of events is completed. 

2. Any set of operations that is repeated 
regularly in the same sequence. The 
operations may be subject to variations 
en each repetition. 

Data. Any representation, such as charac- 
ter quantities, to which meaning might be 
assigned. 
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fi^i§i_l!ii§« A collection of related records 
treated as a unit and consisting of data in 
one of several prescribed arrangements and 
described by control information to which 
the system has access. 



^a ta_Ma na^eme nt . See File Management. 



£§i§_l£2cessi na . A systematic sequence of 
operations performed on data. 



Data gr ocessinq System. A network of 
machine components capable of accepting 
information, processing it according to a 
plan, and producing the desired results. 

Data Record. See Logical Record. 

Eata_Set. See Data File. 

Decimal . 

1. A characteristic or property involving 
a selection, choice or condition in 
which there are ten possibilities. 

2. The number representation system with a 
base of ten. 

Deck. A collection of punched cards. 

Defauit_ Value . The operand specification 
assumed by a program when the value is 
omitted . 

Descepdinq Order. A sequence of records 
such that the control fields of each suc- 
cessive record collate equal to or lower 
than those of the preceding record. 

Digit. 

1. Any of the arable numerals 1 to 9 and 
the symbol 0. 

2. One of the elements that combine to 
form numbers in a system other than the 
decimal system. 

EBCDIC. (Extended Binary Coded Decimal 
Interchange Code) A specific set of eight- 
bit codes standard throughout System/360. 

Error. A general term to indicate that a 
data value is not correct or that a machine 
component is malfunctioning. 

File . A collection of related records 
treated as a unit, e.g., in inventory con- 
trol, one line of an invoice forms an item, 
a complete invoice forms a record, and the 
complete set of such records forms a file. 

F il e_Ma naae me nt . A general term that 
collectively describes those functions of 
the control program that provide access to 
files, enforce data storage conventions, 
and regulate the use of input/output 
devices. 



FixedrLength Record. A record having the 
same length as all other records with which 
it is logically or physically associated. 



Half word_Bgundary . Even- numbered byte 
position in main storage, coincident with 
the left byte of a halfword. 

l§x 3[^6cimal . A number system using the 
equivalent of the decimal number 16 as a 
base. The values 0-15 are represented by 
the digits 0-9 and the alphabetic charac- 
ters A-F. 

Ho££er. A device that holds cards and 
makes them available to a card feed 
mechanism. Contrast with card stacker. 

Indexing. A technique of address modifica- 
tion often implemented by means of index 
registers. 

Index ..Regis ter . A register whose contents 
is added to or subtracted from the operand 
address prior to or during the execution of 
an instruction. 

Initialize. To set certain counters, 
switches and addresses at specified times 
in a computer routine. 

I n£u t . 

1. The data to be processed. 

2. The state or sequence of states occur- 
ring on a specified input channel. 

3. The device or collective set of devices 
used for bringing data into another 
device. 

4. A channel for impressing a state on a 
device or logic element. 

ll3£J^i_ Ar ea . The area of internal storage 
into which data is transferred from extern- 
al storage. 

I J}£ui/ Output. 

1. Common abbreviation I/C. A general 
term for the equipment used to commun- 
icate with a computer. 

2. The data involved in such 
communication. 

3. The media carrying the data for 
input/output. 

Instruction. A statement that specifies an 
operation and the values or locations of 
all operands. In this context, the term 
instruction is preferable to the terms com- 
mand cr order which are sometimes used as 
synonyms. Command should be reserved for 
electronic signals. Crder should be 
reserved for sequence, interpolation and 
related usage. 

lijs t r U5iioU_lo£15i • l^^e allocation of bits 
or characters of a machine instruction to 
specific functions. 
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Interrupt . 

1. A break in the normal flow of a system 
or routine such that the flow can be 
resumed from that point at a later 
time . 

2. To cause an interrupt 



I/0_Area. An area (portion) of main 
storage into which data is read or from 
which data is written. I/O means 
Input/Output. 

^2i_Control_Proc[ram. A System Control pro- 
gram. Called into main storage between 
jobs and provides for automatic job-to- job 
transmission. Processes control statements 
in the input stream that identify a job or 
define its requirements and options. 

Label. A physical identification record on 
magnetic tape (or disk) . 

Linkage. The interconnections between a 
main routine and a closed routine ,i .e. , 
entry and exit for a closed routine from 
the main routine. 

Load . To place data into internal storage. 

iocation. A position in storage that is 
usually identified by an address. 

Lo^ica l_Reco rd . A record identified from 
the standpoint of its content, function, 
and use rather than its physical attri- 
butes. It is meaningful with respect to 
the information it contains. (Contrast 
with Physical Record.) 

Machine_Inst ruction. An instruction that 
the particular machine can recognize and 
execute . 

iJ^cr o_I ns t r uc tion . A statement that is 
used in a source program and replaced by a 
specific sequence of machine instructions 
in the associated object program. 

Macro Libra ry tl^£iil« ^^ area of the macro 

library section of the system tape. Has 
four priority sections, each of which con- 
tains the macro definitions required by the 
macro instructions in user programs. 

Magnetic Tape. A tape with a magnetic sur- 
face on which data can be stored. 

Main_Storage. The fastest general purpose 
storage of a computer. Also, for the Model 
20, storage within the CPU that can be 
addressed both for reading and writing 
data. 

Mn emo nic Code. A mnemonic code resembles 
the original word and is usually easy to 
remember, e.g., ID for edit and MVC for 
move characters. 



Name. An alphameric character string, 
normally used to identify a program. 

Cbject_ Frog ram. A fully assembled program 
ready to be loaded in the computer. 

Operand. That which is operated upon. An 
operand is usually identified by an address 
part of an instruction. 

Ope ration . 

1. The act specified by a single computer 
instruction. 

2. A program step undertaken or executed 
by a computer, e.g., addition, multip- 
lication, extraction, comparison, 
shift, or transfer. The operation is 
usually specified by the operation part 
of an instruction. 

Operation Code. The code that represents 
the specific operations of a computer. 

C u t^ u t . 

1. Data that has been processed. 

2. The state or sequence of states occur- 
ring on a specified output channel. 

3. The device or collective set of devices 
used for taking data out of a device. 

4. A channel for expressing a state on a 
device or logic element. 

Output Area. The area of internal storage 
from which data is transferred to external 
storage. 

Overlap . To do something at the same time 
that something else is being done; for 
example, to perform input/output operations 
while instructions are being executed by 
the central processing unit. 

Overlay . To place a phase or subphase into 
main storage locations occupied by another 
phase or subphase that has already been 
processed. 

Pack. To combine two or more units of 
information into a single physical unit to 
conserve storage. 

Paddin g. A technique used to fill a block 
of information with dummy records, words or 
characters. 

Physical Record. A record identified from 
the standpoint of the manner or form in 
which it is stored and retrieved; that is, 
one that is meaningful with respect to 
access. (Contrast with Logical Record.) 

Pro blgm Program. A general term for any 
program that is not a control program. 

Program . 

1 . The plan for the solution of a problem 

including data gathering, processing 

and reporting. 
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2. A group of related routines which solve 
a given problem. 

Process. A systematic sequence of opera- 
tions to produce a specified result. 

Re§,d, To transfer information from an 
input device to internal or auxiliary 
storage. 

Bead/Compute, Write/Compute OyerlapFea- 
ture. A feature of the IBM System/360 
Model 2C, Submodel 5 that permits data 
transfer from or to I/O units to be over- 
lapped with processing. 

Header. A device which converts informa- 
tion in one form of storage to information 
in another form of storage. 

Reblock. To change the format of a file so 
that a different number of logical records 
comprises one physical record. See Block. 

Record. A general term for any unit of 
data that is distinct from all others when 
considered in a particular context. 

Register. A device capable of storing a 
specified amount of data such as one 
halfword. 

Relocate. In programming, to move a rou- 
tine from one portion of internal storage 
to another and to automatically adjust the 
necessary address references so that the 
routine, in its new location, can be 
executed . 

Sei2£§:iioU • The modification of address 
constants required to compensate for a 
change of origin of a phase or subphase. 

Routine. An ordered set of instructions 
that may have some general or frequent use. 

RWC Feature. See Read/Compute, Krite/ 
Compute Overlap Feature. 

So urce_La n^ua^e . A language that is an 
input to a given translation process. 

Source Program. A program written in a 
source language. 

Special Character. In a character set, a 
character that is neither a numeral nor a 
letter, e.g., -*$ = and blank. 



Jilienent. In computer prograaming, a 
meaningful expression or generalized 
instruction in a source language. 



Storage . 

1 . Pertaining to a device into which data 

can be entered and from which it can be 

retrieved at a later time. 
2. Loosely, any device that can sifore 

data. 



^Igi^gg... Capacity . The amount of data (in 
bytes) that can be contained in a storage 
device. 

Store . 

1. To enter data into a storage device. 

2. To retain data in a storage device. 

Subroutine. A routine that can le part of 
another routine. 

Switch . 

1. A symbol used to indicate a branching 
point, or a set of instructions to con- 
dition a branch. 

2. A physical device which can alter flow. 

Jll bjolic_ A dd ress . An address expressed in 
symbols convenient to the programmer. 



Sjstem. 

1. A collection of consecutive operations 
and procedures required to accomplish a 
specific objective. 

2. An assembly of objects united to form a 
functional unit. 

Tafg_Mark . A special symbol that can be 
read from, or written on, magnetic tape. 
Used to distinguish the end of a file or 
file segment, and to segregate the labels 
from data. 

Truncate. To cut off at a specified spot 
(as contrasted with round or pad) . 

Unpack. To recover the original data from 
packed data. 

Vc 1 u me . That portion of a single unit cf 
storage media that is accessible to a 
single read-write mechanism. For example, 
a reel of magnetic tape for a 2iH5 magnetic 
tape drive, or one 1316 Eisk Pack for a 
2311 Disk Storage Drive. 
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Alternate Tape Drive 23 

ALTTAPE. , 23 

Assembly of IOCS 62 

BACK (READ= specification) 24 

Backspace to Inter-Block Gap . . . . 38, U1 
Backspace to Tape Mark ....... 40,41 

Base Registers, Assignraent of 26 

BINAEI 14 

Binary Synchronous Coramunications Adapter 7 

BLKSIZE 15,22 

Block 8 

Block Count. 41,49,51 

Block-Length Indication 8,9,21 

Blocked Records. 8,36 

Blocking (of Records) 56 

Blocksize. 15^,22 

BSF 40,41 

BSR 40,41 

Card Print Area. 15,16 

Card Printing. ... 16,42,47 

Card/Prijiter Overlap Mode 9 

Checking 

Panel Format .« 18 

Read Format. 17 

Sequence 17 

Checkpoint Record. ., 24 

CKPTREC , 24 

Clear Card-Print Area 16,42 

Clear Output Area. 36,37 

Clear Hork Area. . » 36,37 

CLOSE . 51 

CMBND (TYPEFLE= specification) 14 

CNTRL 37 

combined File, . . 9,15,37 

Compatibility. .....65 

Completion Macro Instructions. ..... 49 

Continuation Punch 12 

CONTROL. 14,23 

Corlrol (Macro Instruction) 37 

Control Statements 

Tape Label 55 

Volume 55 

CRDPR. . ' 41 

CRDPRA 16 

CRDPRLn 16 

CRP20 (DEVICE= specification) 13 

Data Conversion Feature. ....... 6,7 

Deblocking Cof Records) .........56 

Definition Statement Summary 

Card and Printer Files ....... 27 

Tape Files 30 

Definition Statements 11 

Delayed Skipping 39 

Delayed Spacing. 39 

Detail Entries 12,27,30 

DTFHT 18,30 



DTFSR 13,27 

for card printing. 16 

for checking functions 16 

for combined files 15 

for simple files 14 

for tape files .18 

DEVADDB 19 

DEVICE 13 

Device Error Recovery 61 

DTF Block 59 

DTFBG Statement 12 

DTFEH Statement 11,24 

DTFMT Detail Entries 18 

DTFMT Statement 11 

DTFSR Detail Entries .13 

DTFSl Statement 11 

Dummy GET Macro Instruction 45 

End-of-File 14,22,50 

End-of-Volume 24,50 

Enter Overlap Mode 42 

EOFADDR 14,22 

EOH ;. 37,42,43 

Erase, Gap 41 

ERG 41 

ERRIO 21 

EREGPT 20,21 

Error Option ..... 20 

Error Recovery ..61 

FEOV 52 

FETCH 25 

FItABL 19,20 

File 9 

File Definition Statement. 11 

File Name 35,64 

FIXBLK (RECFORM= specification) 19 

Fixed-Length Records 8,19,36 

FTXUNB (RECFOEM= specification) 19 

Form Skipping 39 

Format of 

Definition Statement 12 

Macro Instruction. 11 

Records 7 

FORWARD (READ= specification) 24 

Forward Space to Inter-Block Gap .... 40 

Forward Space to Tape Mark 40 

FSF 40,41 

FSR 40,41 

Functions of IOCS. 5 

General Programming Considerations ... 56 

GET 34 

GET, Dummy 45 

Halt and Restart Information (WAITC) . . 44 
Header Entries 12 
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IGNORE (ERROPT= specification) 20 

Immediate Skipping 39 

Immediate Spacing ...39 

Imperative Hacro Instructions, . . 5,11,53 

INAREA 15 

INBLKSZ 15 

Initialization Hacro Instruction .... 32 

Input Area ^^,3^,51 

Input/Output Devices 6 

INPUT 

{BINASY= specification) 14 

(TYPErLE= specification) .... 13,19 

I0AREA1 14,22 

I0AREA2 15,19,22 

IOCS 

Assembly of ..62 

Functions of..... 5 

Other Programs used by 5 

1259/1419 Macro Instructions .... 22 
lOREG 22 

Keyword 12 

LABADDR 20 

Label 

Definition ........ 9 

Checking Routine 20 

Processing 32,48 

Return 48 

Language Compatibility 65 

LBEET 48 

Leave Overlap Mode 42 

Literals 6,25 

Loading Program Phases ...... 25,44,48 

Logical Record ...... 8 

LOM. 42 

Lower Feed Print Area 15 

Machine Features Supported ....... 6 

Machine Requirements ..... 5 

Macro Definition, User Written ..... 25 

Macro Instructions 11 

Card and Printer File 41 

Common (all Files) 34 

Completion 49 

Declarative 11 

Imperative ,.11 

Initialization 32 

Processing 33 

Tape File 48 

Maximum Block length 15,22 

Maximum Record Length. 20 

Maximum System Configuration 6 

MFCM1 (DEVICE= specification) 13 

MFCM2 (DEVTCE= specification) 13 

Minimum Block Length . 15,22 

Minimum Record Length. .... 20 

Minimum Sytem Configuration. ...... 6 

Name of 

Card Print Area 15 

Input/Output Areas 14,22 

User Routines 14,17,20 

Names (Symbols) 62 



Non-overlap Mode ......... 9,14,37 

NORWD (REWIND= specification) 24 

NSTD (FILABL= specification) 20 

OPEN 32 

ORG 25 

OUAREA 15 

OUBtKSZ. 15 

OUTPUT (TYPEFLE= specification), . . 14,19 

Output Area 14,22,35,57 

OVERLAP 14 

Overlap Mode . 9,14,37,58 

Overlay 26,24 

OVLAY. ..... 24 

PFOBHTn , 18 

PFXIT 18 

Print Area , 15 

PRINTER (DEVICE= specification) 13 

Printer Overflow ,. 43 

PRINTLF (DEVICE= specification) 13 

PRINTOV 14 

PRINTDF (DEVICE= specification) 13 

Programming Considerations 

Combined Files 37 

EOM and LOM 43 

General 56 

Programming Examples ...66 

PrograniBing with WAITC 44 

Programs, others used by IOCS 5 

PRTOV. 43 

Punch Format Checking. .........18 

Punched Card Equipment Errors 61 

PUNCH20 (DEVICE= specification) 13 

PUNCH42 (DEVICE= specification) 13 

PUT 35,36,37 

READ , 24 

Read Backward. ..... 21,24,33 

Read-Format Checking 17 

Read/Compute, Write/Compute 

Overlap Feature , 9,12,58 

READ01 (DEVICE= specification) 13 

RECFORM 19,21 

Record Length 15,19 

Record-Length Indication ....... 8,19 

Records 

Blocking of .56 

Checkpoint 24 

Deblocking of 56 

Definition of, 8 

Fixed-Length 8,19 

Format of 8,19 

Format permitted ,,,....... 9 

Undefined Format . 9 

Variable-Length 8,19,34 

RECSI2E 19 

Registers 

lOREG 22 

RECSIZE 19 

Requirements of. . 59 

Usage of 62 

VARBLD 23 

Release (processing of block) 48 

RELSE 41,48 
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Seopen Files 51 

Requirements fcr WAITC ....,,.,. 14U 

R£W. 41 

REWIND 24 

Rewind and Unload Tape 41 

Rewind Tape 24,41 

RFORMTn 17 

RFXIT 18 

RUN. 41 

RHC, see Read/Compute, Write/Compute 

SEQNCE 17 

Sequence Checking 17 

SEQXIT 17 

Simple File 9 

SK 39 

SKIP {EBBOPT= specification) 20 

Skipping 39 

SP . 39 

Spacing 39 

SPSW 64 

SS (stacker select mnemonic) 37 

Stacker Select 37 

Standard Labels 23,9,32,50 

STD {FILABL= specification) . . 20 

Summary 

Definition Statements, Card/Printer. 27 

Definition Statements, Tape Files. . 30 

Imperative Macro Instructions. ... 53 

Symbols 64 

SYSnnn 

(ALTTAPE= specification) 23 

(DEVADDE= specification) 19 

SYSIPT 

(ALTTAPE= specification) 23 

(DEVADDE= specification) 19 

SYS OPT 

(ALTTAPE= specification) 23 

(DEVADDR= specification) 19 

Tape 

Error Routines 61 

Input File 51,19,32,48 

Label Statements 55 



Mark 24,51 

Output File 51,48,19,33 

Unit Control 40 

Time Sharing Feature 5 

TPMARK 24 

Translate Feature 6,7 

TRUNC 41,49 

Truncate (block) 49 

TYPEFLE 13,19 

Unblocked Records 8 

UNDEF (RECFORH= specification) 19 

Undefined Format Records 9,19,36 

UNLOAD (REflIND= specification) 24 

Unloading Tape 24 

Upper-Feed Print Area .15 

Usage of Registers 59,62 

User Label Routine 20,48,49 

User Standard Labels 20,32,48 

User-Written Macro Definition. 25 

VAHBLD 2 3 

VARBLK (RECFORH= specification) 19 

Variable-Length Records 8,19,34 

VAEUNB (RECFORn= specification) 19 

Volume ..... 9 

Volume Statement 55 

WAITC 44 

Halt and Restart Information . . 44,46 

Programming with 44 

Requirements for 44 

WLRERR 21 

Work Area 14,22,34,57 

WOEKA 14,22 

Write Tape Mark ....41 

TIrong-Iength Block (Record) 21,21 

WTM 41 

XFR 25 

XIO 64 
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